- Arch-projects - lists.archlinux.org

[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

[arch-projects] A little project of mine...
by Joao Estevao 31 Aug '05

31 Aug '05

Hello, I don't know if you guys check the forums but I've been coding a pacman front end in pygtk, and I'd like to make this announcement here as well. It's called guzuta, after the orange monster in Pac-Man game, and here is the project homepage http://guzuta.berlios.de/ and a PKGBUILD can be found here: http://aur.archlinux.org/packages.php?do_Details=1&ID=1800 -- 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] Distro Talk idea
by Jason Chu 05 Aug '05

05 Aug '05

Something that Arch can always benefit from is knowledge of how other distros do things. We don't always make the same choices as the other distros, but at least being informed about other methods and their consequences helps to find a better solution in the end. I'm thinking that a whole site dedicated to intelligent discussion about distros would be really cool and helpful. A couple of guidelines would have to be in place: 1) People get LARTed very quickly -- have to nip the distro war mind-set in the bud. 2) Every distro is equal (much like linguists consider every language to be equal). Just because one distro does something different doesn't mean that it's bad. You have to look at the relative merits of everything. 3) The discussions are for the betterment of all distros, all (well thought out) opinions are valid for their own reasons. No distro should be excluded from the discussion. Some of the technologies we figured was an article system like osnews, where intelligent articles about tools, methodologies, etc for a given distro can posted, with comments. Also a general discussion mailing list. Both would (hopefully) be community taggable ;o) It'd be the first place to have something like that. It'd be cool if people could request articles about certain topics to help expand their own knowledge (especially to gain insight into a problem they're having right now). This site would really only be for smart people who have good ideas to offer to the distro development community. Anyone else need not apply ;) What do you guys think? Good idea? Not? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.

3 3

Fwd: Re: [arch-projects] Keeping the list alive!
by Andy Roberts 01 Aug '05

01 Aug '05

I'll forward this for Rasat as he only sent it to me but I expect it was for all. ---------- Forwarded Message ---------- Subject: Re: [arch-projects] Keeping the list alive! Date: Monday 01 Aug 2005 15:45 From: Rasatmakananda <rasat(a)pacific.net.sg> To: Andy Roberts <mail(a)andy-roberts.net> On Mon, 2005-08-01 at 15:19 +0000, Andy Roberts wrote: > > .... the selection of > > language is also part of Arch's concept of KISS. > > http://bbs.archlinux.org/viewtopic.php?t=13576 > > This is surely from a programmers perspective, i.e., languages that make > programming easy. I really don't think that language choice was part of > Judd's vision, since he's a C programmer. Not Judd's vision but somehow the choice of C and Bash were the right languages making Arch an ideal distro where users can easily hack and configure as they want. This is the main factor in Arch. Not only a product to use but anyone who is interested can easily develop on their own or join in Arch development. What I am trying to say here, most of the Archers are "devs" in one way or other, or learn to become because of user contributions. Therefore loves in products/projects what is simple in performance and easy to help/hack for further improvement. If one sided, the language is too troublesome to read/hack, they may still use the product but will not show interest. The Arch Way: "Don't let configure tools / GUIs control the system but be controlled by the user". In my recent understanding, this principle applies not only, not to be controlled in configure matters but also not to be depended what tools offer. A tool should be hackable to be able to makes things as user want..... not what the tool want (smile). Rasat

1 0

[arch-projects] Keeping the list alive!
by Andy Roberts 01 Aug '05

01 Aug '05

Hi all, I thought I'd give everyone a nudge to chip in with updates on their current project(s). This month, I have been mostly writing Jacman. (Fast show, anyone?!) So, c'mon guys, be honest... has it been worth my effort? Do you think people actually will use it? Does ArchLinux *need* such a utility? Or did I pick the wrong language? Bearing in mind that Archie won't use Jacman due to the size of the JRE. It's not that I haven't had lots of positive feedback. And even if no-one else liked it, it's certainly been good for practising Java GUI programming and how to interact with native commands. I'm just wondering what you guys think. What are you lot up to? Andy

3 7

[arch-projects] Number Munchers
by Dusty Phillips 23 Jul '05

23 Jul '05

Here again, it lies with me to try to keep this poor list alive. I don't know if you guys just stop doing projects or what. ;-) I've been experimenting with Blender, Soya, and Python. I'm not very good with any of them, though the latter two are pretty much brainless. To try and improve my skills, I've decided to write a small 3D version of Number Munchers. I don't aim to make it a complete emulation or anything, just something to get used to the 3D programming a la Python (ie: no TransformGroups or vecmath package). Problem is, I don't remember much about Number Munchers. I was wondering if I could feed off your collective memories -- we seem to be approximately the age group that grew up on Apple IIe... god how time flies. Some of the things I'd like to sort of remember is the sort of levels that were available. All I remember is 'factors of 2' and 'multiples of 2'. I also don't remember much about the trogs (I *think* that's what the bad guys were called)... they each had distinct names and behaviors, I think. I think that the higher you went, the harder the levels became (factors of 8), the more advanced the trogs' tracking systems were, and the more trogs there might be on the screen at one time. I just don't remember details. My first aim will be to get a purple 8x8 grid (was it 8x8 or 10x10?) and a 3D green boxy character that will walk around on it. The camera will follow the character, at about 45 or maybe 60 degrees above the playing surface so that most of it can be seen at once. After that, I want to get the level generation code working, so that numbers show up and the guy (any idea what his name was? muncher?) has to walk around eating the correct ones. Next, I'll try to get the trog characters animated. That'll be it. Nice simple three-milestone release. I may never get to it, since I'm supposedly taking the month of August off from computers. :-D Any ideas? Anybody remember this game? Damn, next thing you know I'll be doing 3D oregon trail... Dusty

4 8

[arch-projects] Arch Linux Java Packaging
by Dusty Phillips 04 Jun '05

04 Jun '05

Hey folks, I'd like some peer review on this document before releasing it to the hungry masses to tear apart and unconstructively criticize... http://www.buchuki.com/misc/archjava.html Jason: Could you post a link to this on the Developer Mailing list? They can direct any questions to me or discuss it amoungst themselves first. ;-) For those who don't like to randomly click links in an e-mail without knowing what they are, this is a first draft of a document I wrote that defines a new standard for packaging java applications. I'm looking for feedback and potential problems so they can be adjust or changed within the document. Dusty

1 0