From: Christian K. <kre...@in...> - 2002-02-20 10:29:11
|
"Carsten Haitzler (The Rasterman)" wrote: > > the one thing that makes me come back to ferite for external epplets is... no > need to compile or install etc. just put external epplet in a dir. ferite > external epplet executer takes care of it... i know what you are saying by C is > fine... but what it does do is makes getting an external epplet running one (or > 2 or 3) steps easier for the end user... also easier for people to write their > own epplets - they dont need to know miuch (ok - that could be a bad thing too!) > :) > > i think this bears further discussion... Mhmmm okay there's one thing I still don't get -- ferite for external epplets basically has the same problems as inlining them in e17, except for the concurrency part. I mean, no matter how many default modules ferite will come with, there will always be the possibility for something that they don't provide, then you'll need to add a module, that will need to be compiled, an we lose all advantages. Now, ferite isn't a bad idea in general. I'm thinking if it would be possible to do both. Say we write an e17 <-> epplet ipc library, much like epplets worked in e16, through which you could lay out your epplet, define callbacks etc. Let's wrap a ferite module around it. Then people could use ferite when they want to but also directly use the ipc lib from C/C++ when they have to? I also think that ipc library is doable. I guess we could keep the size of epplets fixed. There are about 4 people per year complaining about that, and it saves so much hassle. So we could have calls like epplet_create() /* maybe with your category idea here, Raster */ epplet_add_button(0,0, my_button_callback); and the button would appear in the top left of the epplet, the view evas can register a callback for the button, and the events are basically propagated through the ipc channel so that in the end our callback gets called by the epplet library etc. > ** continuing from other threads... lets put it in here now ** > > time to unify this. > > we need to move things > > directory/.e_layout/ > > put our "layout" info in here. > > in there we can have: > > directory/.e_layout/epplets/ > > in which you put a directory-per-epplet. ie: > directory/.e_layout/epplets/epplet-name/bin > > this would be a "binary" executable - just like any other on your system. when > the directory is opened this is executed (with given environment variables so it > knows how to talk back to e) - this of course would only be done for > "sanctioned" directories (ie ~/.e/desktop - or anything that matches a glob in > in the list of "approved" directories. if you have "/*" in that list of approved > directories.. guess what.. all directories will do this. have an empty list and > none will do it... anyway.. that should make the security people happy. by > default we would have: "~/.e/desktop/*" in there (ie all desktop dirs of the > user)) > > thee would be also > directory/.e_layout/epplets/epplet-name/bin.fe > > if no bin file was found. bin.fe will be looked for and executed inline in e as > a plugin. > > that directory (ie directory/.e_layout/epplets/epplet-name/) should contain all > data the epplet needs (or symlinks to it) - ie bits, images, sounds, fonts etc. > > this way an epplet is easily installable and un-installable > > this needs to be fixed. any comments accepted. I like the idea of strongly relying on the filesystem to structure things, I thought about that too and it's exactly what I would have suggested. > second. layout > we need to organise where things go: > > directoy/.e_layout/layout.bits.db > > this would be the bits file that specified where everything goes in that view > (if that view is the desktop view... it will also be able to specify where > application windows go) > > Imagine this is your whole desktop (or any file view): > > +-+-------------+ > | | F | > | +-----++------+ > |I| A1 || A2 | > | | || | > | | || | > +-+ ++------+ > |E| | A3 | > |1| | | > | +-----+-------+ > | | E2 | > +-+-------------+ (I must be on drugs -- this just reminded me of a Mondrian picture :) Help!) > This would be an ebits file (layout.bits.db). it may or may not contain image > data (just like the e_iconbar.bits.db now) that may decorate this. this could be > little gray panels, ivy leaves, b & w lines... bevels... or just blank - ie no > decoration images in the bits file. > > in this example... > I = Iconbar area. all launcher icons in the iconbar get laid out here . we > probably should have a horizontal and a vertical one - so it knows explicitly > how to lay them out.. currently it guesses from the size of the area. F = Files > area. The view will put all file icons in this area and lay them out here... E1 > = Epplet area one. (probably should be able to name epplet areas). epplets can > live in their named area (where the user said they want the epplet to go - or > where by default it wants to do until the user moves it). you can have as many > epplet areas as you like (or iconbar... etc.) E2 = another epplet area > A1 = Application area 1 > A2 = Application area 2 > A3 = application area 3 > > you can have as many app areas as you want. apps will be placed in whatever app > area they were told to live in (with remembering) or whatever app area they fit > in best. apps will "resist" being dragged out of app area - just like they > resist other app window borders and screen edges. Yup, that way we silence all those "can I prevent windows from being moved over my epplets, taskbar, etc". > again we should name epplet areas - like "terminals" "web" "irc" etc. > so apps look for their named app area to go to.. like epplets That's maybe a bit too much for me :) > of course for all directories on the system that didn't have their own layout > setup.. we can have a template directory that will determine the default layout > for all directory views.. including background etc. etc. Yeah. Sounds all good and doable so far. One thing nobody mentioned in a long time: the typebuffer. It's fairly essential to keep the benefits of the command line combined with those of the gui. I would keep it as a "one-line terminal" at the bottom of the view. I didn't really like the timeout in efm and the fact that it disappeared after a while. We could add pull-down menus to easily select recent commands etc. There's another thing I thought of that I'd like to mention: we're combining a wm and a file manager here, nobody has done that so far, so I think we have additional possibilities here: say that we open new views in the same existing view instead of popping up a new one (I guess we agree that at least this needs to be configurable). Then we'll want to have a history and typically a left, right, and up arrow somewhere to go to the prev and next dirs in the history, and to the .. directory. These are fairly essential buttons, and since our wm actually has a clue about what is contained in a window ... how about providing means to put these buttons in the window border? I sketched up the idea here: http://www.whoop.org/downloads/file-view.jpg . I love this, and it would save even more space. Anyway, enough food for thought ... Christian. -- ________________________________________________________________________ http://www.whoop.org |