- Arch-projects - lists.archlinux.org

Re: [arch-projects] test email?
by Aaron Griffin 15 May '07

15 May '07

On 5/15/07, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > > Mailman? save me!

1 0

[arch-projects] test
by Giovanni Scafora 29 Mar '07

29 Mar '07

test

2 1

[arch-projects] PkgData -- in what format?
by Rasatmakananda 26 Jun '06

26 Jun '06

Hi, PkgData contains additional Arch package information with detail, type of application, and thumbnail. Currently has about 60% of all both current and extra. Each information is in separate file with package named + extension (dsc, app, or jpg). Example: alsaplayer.app Multimedia :: SoundAudio :: Players :: MP3 alsaplayer.dsc AlsaPlayer is a new PCM player written with the ALSA sound system in mind. It also includes support for JACK, OSS, NAS, and ESD. It makes extensive use of multi-threading and supports OGG, MP3, WAV, CDDA (CD Digital Audio), MOD, S3M, IT, and many other input types. Features include a real- time effects stream, variable speed/pitch control, SHOUTcast/icecast streaming support, multiple active visual scopes, command line mode, playlists, plugin architecture, low-latency mode, and more. alsaplayer.jpg 148x115 thumbnail Originally from freshmeat.net http://freshmeat.net/projects/alsaplayer/ Pkgdata is for front-end package managers. Doesn't have a search engine by itself. The search is done in a front-end finding e.g. MP3" packages or "Video" within "multimedia" category (if abs tree is included). Or "Cryptography" or "IDE" within "devel" category. Sample in PkgInfo (ruby front-end): http://user-contributions.org/projects/pkginfo/pkginfo.jpg My question here, what would be most convenient format for the developers? The abs tree has information in one file and structured within directories. Is this most convenient or separate files as they are now, or other format? Rasat

1 0

[arch-projects] Meeting reminder
by Jason Chu 16 Feb '06

16 Feb '06

This message is just to remind everyone of the ports meeting in #archlinux64 at 10:00 AM PST on Feb, 19th. Hope to see you there, Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.

1 0

[arch-projects] python wrapper for libalpm
by Joao Estevao 12 Dec '05

12 Dec '05

Hello, this is just to announce to anyone who's interested that I've pretty much finished the libalpm python integration, codenamed PYneALPM. So if anyone would like to try it, contribute, flame me, go ahead. PKGBUILD: http://pwp.netcabo.pt/tranquility/pynealpm/PKGBUILD Source: http://pwp.netcabo.pt/tranquility/pynealpm/pynealpm-0.0.0.tar.bz2 The libalpm PKGBUILD I've been using: http://pwp.netcabo.pt/tranquility/pynealpm/PKGBUILD.libalpm -- A mind all logic is like a knife all blade. It makes the hand bleed that uses it. -- Rabindranath Tagore (1861-1941)

1 0

[arch-projects] Triple editor help
by Rasatmakananda 28 Oct '05

28 Oct '05

Any of you are interested and have time to make one simple editor with 1 + 3 windows. Purpose is to copy parts from an original file and paste in three different files. Here is an edited screenshot how it will look: http://user-contributions.org/projects/archwd/screenshots/triple-editor.jpg Its preferable to use a language what most likely pre-installed by the user. Rasat

2 2

[arch-projects] Modular Text Editor
by Dusty Phillips 18 Oct '05

18 Oct '05

If this has been done, I'd really like to see where. I'm really getting tired of the messy hacks that text editors tend to be, with features I never use and so forth. I want to build a text editor that allows you to install features one at a time (sounds like the archwm philosophy, eh?) I don't have time to do this, I was wondering if I could gain support. Basically, here's what I'm thinking: There is an extremely simple main editor component (written in python). This provides basic text editing and an extension/plugin/macro language. Then you can use import statements in a config to import editor modules that you are interested in. Such modules would provide syntax highlighting, keyboard shortcuts, menubars (I'd never install this, but somebody else might), toolbars (ditto), code completion, abbreviations, search and replace etc. Finally, you can have usually very short configuration scripts that provide additional customizations (set up your keyboard shortcuts, syntax colours, etc) or macro-like features in your home directory. If possible, it would be cool if these short scripts could be scripted in languages other than python Question 1: How is this different from <insert-favourite-text-editor>? Answer 1: Maybe its not. Maybe you have an editor that I would like to use. I really don't want to write my own editor, but none of the existing tools are elegant enough for me. Please tell me about it, especially if its not a common editor. Answer 2: There is an editor that is similar to what I want. Its known as vim. I have some issues with vim though -- its a real pain to configure, its syntax is what I consider ugly. I don't want to learn yet another language just to configure my editor (Actually, I know how to script vim so I don't have to learn it, but neither do I want to look it up). Answer 3: There is an editor that is similar to what I want. Its known as emacs. Same issues. I mean... Lisp??? Answer 4: There is an editor that is similar to what I want. Its known as JEdit. I've been using JEdit for years. But I'd like something that's a little more streamlined. JEdit has a beautiful Java plugin architecture, and a beautiful beanshell macro interpreter. I don't see why plugins and macros should be different, for example. It also suffers from the same issues as the previous answers -- I mean.... Java? I would borrow a lot of cool ideas from JEdit though if I could. Answer 5: The key thing about my vision of an editor is that each feature is totally optional. It doesn't have "built-in" anything. BUT installing a feature should be as easy as importing some python module. keep it SIMPLE SIMPLE SIMPLE. The main reason for this is I like to rebind practically ALL my keyboard shortcuts, and usually the ones I like are bound to actions I never use, and unbinding them is.... tricky. Question 2: Why reimplement the wheel? Answer 1: Its all been done. This frustrates me. I really don't want to waste time implementing a text editor right now, but I spend so much time in my editor, I'd like something that's got even better HCI than JEdit. That does exactly what I want, not just almost exactly what I want. I've looked at several editors, focusing on python editors lately. There's apparently nothing that suits me. But I don't want to start from scratch. I'm thinking of borrowing from xerces2's lazy-edit (http://xerxes2.1go.dk/python/python_start.php?kap=program.html), and a project nobody's worked on for a while called pyeditor (http://www.rexx.com/~dkuhlman/#special-purpose-scriptable-text-editors) -- the idea behind this project is almost exactly what I want, it just didn't get finished. Answer 2: I really don't want to create an IDE. I want a text editor. Terminals have a purpose, you don't have to embed them into your editor, for god's sake! Debuggers can be run externally. Code navigators..... ok, maybe. The point is, if somebody else wants one of these things, they can create a new module to provide that functionality *without* causing me any pain -- I just won't install it! Question 3: Who's involved? Answer: If nobody would join me, I can't do this on my own at this time, too busy. :-( At this point, I'd like to BEG xerces2 to take an interest in this project, because he's pretty good with PyGTK and has done an editor already. I'd also like to see Mr. Green on board because he's got a pretty good grasp on what sucks in an interface. As an HCI student, I'm learning that those of us who call ourselves programmers are not the best people to be designing user interfaces. Actually, I've been repeatedly beat over the head with this fact... but I digress. I think it would be wonderful to see phrakture and cactus join me, but phrakture is a C++ guy. He's got all that free time though, so maybe he'd make some C++ modules to be embedded in the python interpretter.... Cactus.... well I'd really like to have somebody helping that could help make ruby and python cooperate in this project so that it would fully satisfy both python and ruby programmers. I'd also like to see Xentac and iphitus (python programmers) join me, but I think I'm starting to ask for too much now. Wishful thinking can only go so far. ;-) Question 4: How would you proceed? Assuming I can get at least one good programmer interested in the project (begging xerces2 again, plus anybody else... lol I have no shame), I think I would do the following: Start with lazy-edit and refactor it to allow for fully modular extensions. The extension interface is pretty much the *only* property of the editor itself, besides support for a buffer. I would take out syntax highlighting and the tabbed interface and put them in extensions of their own. This would help test the extension interface. The extension interface would be comprised of allowing extensions protected access to the user interface itself, and providing some sort of 'actions' framework to allow extensions to register actions that could be called back somehow. I would then go on to enhance the syntax highlighting module. It would be nice if it were not necessary to rewrite 'edit modes' for every syntax available. The cool thing would be to steal edit modes from some other editor... JEdit has XML based edit modes; I'm toying with that idea, but I'm not too fond of XML. Then I would work on a totally generic keyboard shortcuts module. It should be fully chainable and beautiful.... configurable in Python. The #1 worst thing in every single editor I have ever used is the horrible GUI interface for customizing keyboard shortcuts. Once I have these two things, I have the two things that I consider really important in a text editor. At that point, I will probably start adding little things here and there as I need them, since I will be using the editor full time. I'm not terribly excited about this project. Its just something I feel resigned to do because no editor I currently use behaves in the way I think it should. I want to believe nobody else likes their editor either, and that our connection (The Arch Philosophy) will allow you to think that this is a good idea. Suggestions are definately welcome. Thanks for your time, Dusty

3 11

[arch-projects] _nus
by eliott 30 Sep '05

30 Sep '05

I have a project I am currently working on, called _nus. http://e.cactuswax.net/index.php/projects/_nus/ _nus is an attempt at a remote server update manager for ArchLinux. Think of it like...the redhat-network, if you are familiar with that. My hope is that people would be able to use it to monitor a large collection of servers, to see which ones are out of date, and to schedule things like adding/removing/updating packages. _nus has two components: A web aggregator, and a monitor daemon. The monitor daemon runs on each of the servers being...monitored. Both are written in ruby (with the rails framework for the web aggregator). I have the monitor daemon code (_nus:Client) mostly framed out. I just need to add the actual 'work' code to it. I am currently working on the web aggregator (_nus:Server) portion. Maveric has been providing me some good feedback, and he said he will provide some testing when I get something usable out. Hopefully this tool will be useful to someone out there. ;) -- Bender: It was horrible! A nightmare! Fry: What happened? Bender: I dreamt I was in a place of 0's and 1's and all of a sudden... I saw a two *whimper* Fry: It's ok Bender, don't worry. There's no such thing as 2's. -------------------------- There are only 10 types of people in the world; those who understand binary and those who don't.

1 0

[arch-projects] Change ArchWM-base to ArchWD?
by Rasatmakananda 29 Sep '05

29 Sep '05

Hi, In the project ArchWM-base, an effort of developing a 'perfect' Window Manager for Arch Linux, something fundamental is missing. I thought the current base (ver. 0.4.9.3) does the job but I don't think it will do, though, the base (not including Pacwm toolkit but the WM side) is good. Here lets consider its 'perfect'. But I still consider something is missing. Users will not be depended what ArchWM-base will offer but can contribute their own modules and features, but still something is missing. The configure for end users became easy by incorporating a runcom system similar to Arch (rc.conf and rc.sysinit), and the coding of all fvwm system files were change to simple format, but still something is missing. It is what you make it, but still something is missing. The missing part is caused by making ArchWM-base into a package and the users will wait for upgrades. It has same affect as the general Linux distributions making the end users depended what's offered. Arch Linux break that tradition by not having fixed releases but a continues upgrade. Also provided a means (ABS) of include users' own packages. The ArchWM-base use the same idea, allowing user contributions, but currently has "fixed" releases. Instead of making an ArchWM-base as an individual package, why not an ArchWD (distro). A "distro" running within Arch. Not only getting rid of the rigid concept of WM (managing windows what is actually quite limited) but creating a new style of "WM" same as Arch did as a distro. The ArchWD still manages the windows but aims to distribute WM and DE related packages (modules and scripts). Not only Fvwm based packages but also others. The style of upgrading the ArchWD system files and user contributed packages, will be same as pacman. The current name "pacwm" toolkit (confusing name) will be changed to "pactk" (package toolkit). To upgrade ArchWD and all installed user packages, simply run in terminal: pactk -Syu Sounds good? Or something is still missing? Wiki: http://user-contributions.org/wikis/userwiki/index.php/ArchWM-base Forum: http://bbs.archlinux.org/viewtopic.php?t=15368 Why Fvwm and not PekWM: http://bbs.archlinux.org/viewtopic.php?t=15222 Markku (rasat)

2 2

[arch-projects] AMD 64 Port
by Jeffrey Zellman 19 Sep '05

19 Sep '05

Hi, I would like to get involved with porting Arch Linux to AMD64. Does anyone have any information on the project? thanks, Jeff -- Peter Griffin: Brian, there's a message in my Alpha Bits. It says "OOOOOO". Brian Griffin: Peter, those are Cheerios.

2 1