From: Christian K. <kre...@in...> - 2002-01-24 10:23:10
|
enl...@li... wrote: > > Enlightenment CVS committal > > Author : rephorm > Project : e17 > Module : apps/e > > Dir : e17/apps/e/src > > Modified Files: > view.c > > Log Message: > > maybe we should get the prefix for gnome from gnome-config --prefix? Sounds good. I wonder if we should move the menu-generating code that scans the gnome apps over to the setup program though, so that we'd consistently have menu dbs within e17. So two of the worksteps the setup program would do would be scanning for kde and gnome apps... Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: <Val...@vt...> - 2002-01-24 19:26:29
|
On Thu, 24 Jan 2002 11:19:57 +0100, Christian Kreibich <kre...@in...> said: > Sounds good. I wonder if we should move the menu-generating code that > scans the gnome apps over to the setup program though, so that we'd Would the "setup program" be accessible dynamically, similar to the e16 "maintenance / regenerate all menus" option? You need to be able to do this so if you install new programs, they'll show up... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech |
From: Carsten H. (T. R. <ra...@ra...> - 2002-01-25 00:54:50
|
On Thu, 24 Jan 2002 14:26:16 -0500 Val...@vt... wrote: > On Thu, 24 Jan 2002 11:19:57 +0100, Christian Kreibich > <kre...@in...> said: > > > Sounds good. I wonder if we should move the menu-generating code that > > scans the gnome apps over to the setup program though, so that we'd > > Would the "setup program" be accessible dynamically, similar to the e16 > "maintenance / regenerate all menus" option? You need to be able to do > this so if you install new programs, they'll show up... i started e_setup - it does nothing atm excpet look pretty. but the idea is it woudl be a wizard run the first time you ever use e17 (or whenever you feel liek starting your setup afresh) that woudl set up your suer config based on 1. speed tests of your machine. if tis slow it woudl suggest a configuration with fancy stuff disabled 2. would see if you uhave gnome or kde (or cde etc.) instaleld and suggest that you may want the gnome & kde menu generators running (and symlink them into ~/.e/startup) 3. would give you an option of your default theme (if we ship more than one) 4. set up iconbars, etc/ for you (let ou choose the profile/style of them etc.) 5. would offer to launch the "online help/guide" proggy to ake you through a quik guided tour of e's features. at this stage.. it just looks pretty :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9439 |
From: Kevin B. <co...@co...> - 2002-01-25 00:18:40
|
Christian Kreibich wrote: > > > Corey Donohoe wrote: > > > > Store the gnome prefix in a db during the setup program or something, > > get the string and regenerate the menus when E runs. do kde menus work > > similar to the gnome ones? I guess we'd need stuff to parse those too. > > The problem is that as far as I know, e17 currently generates them > *once*. So when you install an app while e17 runs and you've used the > menu before, it won't show up. > Somebody needs to read the code... But actually, depends on the menu. The left click E menu is generated on-the-fly from E's menu database. Which I think is kind of neat (but I wrote a menu editor, so I'm biased). Touch the database, and E immediately picks it up. The gnome generation works the same way. right click (it is right click, isn't it?) and E reads the gnome menu structure from disk. Every time... There isn't anything pre-generated for gnome menus presently. > Ideally, this should work as follows: efsd should be able to monitor > directory trees. Create the gnome and/or kde menus initially when the > setup program is run, or maybe the first time e17 is run. Tree-monitor > the gnome and/or kde dirs when e17 is running. If the menus get > modified, rebuild menus in e17. This assumes that kde also uses the fs > for the menus, just as you say... > So there's no need to monitor anything presently... (Unless you want a displayed menu to change dynamically. That's going overboard, isn't it?) > Monitoring a directory tree would really help sometimes. I've been > wondering about that for a while now. The problem is that it's dangerous > if I just descend through the tree and monitor every directory. When > using dnotify, that makes the danger of running out of file descriptors > a lot more real... > > Btw, is it just me or have the icons vanished from the gnome menu? Hmm, I though I had one app in the right click menu, now I have nothing (text or icon). But I updated SuSE recently, so that may be my fault. -- Kevin |
From: Carsten H. (T. R. <ra...@ra...> - 2002-01-25 00:54:50
|
On Thu, 24 Jan 2002 19:18:50 -0500 Kevin Brosius <co...@co...> wrote: > Christian Kreibich wrote: > > > > > > Corey Donohoe wrote: > > > > > > Store the gnome prefix in a db during the setup program or something, > > > get the string and regenerate the menus when E runs. do kde menus work > > > similar to the gnome ones? I guess we'd need stuff to parse those too. > > > > The problem is that as far as I know, e17 currently generates them > > *once*. So when you install an app while e17 runs and you've used the > > menu before, it won't show up. > > > > Somebody needs to read the code... > > But actually, depends on the menu. The left click E menu is generated > on-the-fly from E's menu database. Which I think is kind of neat (but I > wrote a menu editor, so I'm biased). Touch the database, and E > immediately picks it up. > > The gnome generation works the same way. right click (it is right > click, isn't it?) and E reads the gnome menu structure from disk. Every > time... There isn't anything pre-generated for gnome menus presently. errr.... nup. not quite. it only rebuilds if the base dir of the gnome app menu changes - not if anything inside that dir tree changes :) > > Ideally, this should work as follows: efsd should be able to monitor > > directory trees. Create the gnome and/or kde menus initially when the > > setup program is run, or maybe the first time e17 is run. Tree-monitor > > the gnome and/or kde dirs when e17 is running. If the menus get > > modified, rebuild menus in e17. This assumes that kde also uses the fs > > for the menus, just as you say... > > > > So there's no need to monitor anything presently... > > (Unless you want a displayed menu to change dynamically. That's going > overboard, isn't it?) > > > Monitoring a directory tree would really help sometimes. I've been > > wondering about that for a while now. The problem is that it's dangerous > > if I just descend through the tree and monitor every directory. When > > using dnotify, that makes the danger of running out of file descriptors > > a lot more real... > > > > Btw, is it just me or have the icons vanished from the gnome menu? > > Hmm, I though I had one app in the right click menu, now I have nothing > (text or icon). But I updated SuSE recently, so that may be my fault. > > -- > Kevin > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9439 |
From: Christian K. <kre...@in...> - 2002-01-25 12:04:02
|
Hey man :) "Carsten Haitzler (The Rasterman)" wrote: > > personally i'd be happy to have an external app use efsd to monitor the gnome > (and/or) kde dirs and build db menu files quietly in the background. e17 would > pick up the changes. if you dont want the gnome/kde menus.. just dont run the > app (we'll have a "startup" dir - lets say ~/.e/startup where u just dropa > symlink or an executable to be started on login - to make it easy) :) Oooh ... an autostart directory. Nice. Why didn't I think of that yet! > feel free to rip the code out of e17 iself and put it into a stand-alone proggy > :) > > like the idea? Sure, we could do that too. Let's put the issue aside for a while and keep it simple for e17 and regenerate them through the menu tool or whatever, okay? Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Carsten H. (T. R. <ra...@ra...> - 2002-01-27 02:57:41
|
On Fri, 25 Jan 2002 11:58:31 +0100 Christian Kreibich <kre...@in...> wrote: > > Hey man :) > > > "Carsten Haitzler (The Rasterman)" wrote: > > > > personally i'd be happy to have an external app use efsd to monitor the > > gnome(and/or) kde dirs and build db menu files quietly in the background. > > e17 would pick up the changes. if you dont want the gnome/kde menus.. just > > dont run the app (we'll have a "startup" dir - lets say ~/.e/startup where u > > just dropa symlink or an executable to be started on login - to make it > > easy) :) > > Oooh ... an autostart directory. Nice. Why didn't I think of that yet! of course! this is why i thought a file manager woudl be the bets thng to add to e - cause it would make configuring things easy - a matter of directories and files and drag & drop. :) imho epplets should be done the same way :) > > feel free to rip the code out of e17 iself and put it into a stand-alone > > proggy:) > > > > like the idea? > > Sure, we could do that too. Let's put the issue aside for a while and > keep it simple for e17 and regenerate them through the menu tool or > whatever, okay? sounds ok to me (tho the same code woudl be used to regenerate anyway - why not just have it sit in a poll of all the dirs - or let efsd do that... - take your pick :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9439 |
From: Christian K. <kre...@in...> - 2002-01-25 20:33:18
|
Blake Barnett wrote: > > On Fri, 2002-01-25 at 12:20, Lyle Kempler wrote: > > Of course. But I think we're at a point now where we should zero in on > > what needs doing and not take on any new work, and we can stop working > > on it ad-hoc: like you say below, we can write down who's doing what, > > and coordinate better. > > IMHO, what it's going to take is for someone to step up to the plate to > manage/plan/coordinate this project. All the other successful I don't think people ever step up to that, they get suggested, or rather, everyone else steps back a bit :) Seriously though, I agree with what you're saying, although at the moment that coordinator would be lacking the coders to coordinate ... there's only a handful. I don't think we're doing bad. We're in the progress of setting up a feature list and can probably set that in stone (well sort of) in a week or so, and then nail the issues one by one. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: <Val...@vt...> - 2002-01-26 20:05:51
|
On Sat, 26 Jan 2002 19:25:31 +0100, Christian Kreibich <kre...@in...> said: > Do not go overboard with the colors, there are plans to allow tinting of > the gui elements dynamically for the next generation of themes (the > colorclass mechanism in ebits), so that there's no longer any need for > all those cloned themes on themes.org ("It's Brushedmetal, but I wanted > it in blue"). YAY! YAY! Thank you! ;) With e16 I use a slightly modified Ganymede theme, and having blue/green/red/ etc variants of "the same damned image" made it a lot larger and a pain to work with. Now to *really* provide theme-writing joy, if there were just 2 other primitives available: 1) "rotate image 90/180/270" (other angles are *not* really needed, and multiples of 90 are easy to code) so you can say "use *this* image, at 'normal' orientation for a horizontal border, but rotate 90 for a vertical". 2) mirror/flip/reverse image (call it what you want). This would allow you to build 'shade from above/below' easily. And combined with (1), you get shade from left/rigth as well. Given those two, you can with one image for a border create basically any combination of horizontal/vertical with shading from top/bottom/left/right. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech |
From: <Val...@vt...> - 2002-01-26 22:15:20
|
On Sat, 26 Jan 2002 22:32:22 +0100, Christian Kreibich <kre...@in...> said: > Right! I guess these would be really nice features for etcher... I was thinking of them on a par with colorclass, so you could say in the theme stuff like: IMAGE foo.png COLORCLASS {r/g/b/a) ROTATE (0/90/180/270) FLIP/NOFLIP My Ganymede theme has literally *39* different .png for a top titlebar image, *all* of which could be represented in terms of colorclass/rotate/flip as variants of *one* image. And there's about 24 more "rotated" ones that I'd like to use (there's 4 color schemes, only one of which has a 'rotated' version, mostly because currently it's a pain to deal with ;) No, I don't know how you'd express it in the database-flavored theme, but you'd need only 3 bits (2 for rotate and one for flip) to do it. And a little bit of code to interpret it inside the main e17 engine, and a few click buttons in the GUI to set them ;) /Valdis |
From: Carsten H. (T. R. <ra...@ra...> - 2002-01-27 02:57:41
|
On Sat, 26 Jan 2002 15:05:42 -0500 Val...@vt... wrote: > On Sat, 26 Jan 2002 19:25:31 +0100, Christian Kreibich > <kre...@in...> said: > > > Do not go overboard with the colors, there are plans to allow tinting of > > the gui elements dynamically for the next generation of themes (the > > colorclass mechanism in ebits), so that there's no longer any need for > > all those cloned themes on themes.org ("It's Brushedmetal, but I wanted > > it in blue"). > > YAY! YAY! Thank you! ;) > > With e16 I use a slightly modified Ganymede theme, and having blue/green/red/ > etc variants of "the same damned image" made it a lot larger and a pain to > work with. > > Now to *really* provide theme-writing joy, if there were just 2 other > primitives available: > 1) "rotate image 90/180/270" (other angles are *not* really needed, and > multiples of 90 are easy to code) so you can say "use *this* image, at > 'normal' orientation for a horizontal border, but rotate 90 for a vertical". evas doesnt supprot that :) then again it is just a click away in gimp - and most images done look quite right just rotated (u need to get the shading right again too) (some may look right tho - but nto many) > 2) mirror/flip/reverse image (call it what you want). This would allow you > to build 'shade from above/below' easily. And combined with (1), you get > shade from left/rigth as well. sometimes - bu most things are drawn "3d" and just rotating changed the lighting angle to be opposit (or flipping etc.) so it needs re-drawing anyway for most cases :) > Given those two, you can with one image for a border create basically > any combination of horizontal/vertical with shading from > top/bottom/left/right. > > -- > Valdis Kletnieks > Computer Systems Senior Engineer > Virginia Tech > > > -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9439 |
From: Franz M. <fra...@mi...> - 2002-01-29 08:51:32
|
On Sun, 27 Jan 2002, Carsten Haitzler wrote: > > 1) "rotate image 90/180/270" (other angles are *not* really needed, and > > multiples of 90 are easy to code) so you can say "use *this* image, at > > 'normal' orientation for a horizontal border, but rotate 90 for a vertical". > > evas doesnt supprot that :) then again it is just a click away in gimp - and > most images done look quite right just rotated (u need to get the shading right > again too) (some may look right tho - but nto many) Yeah, but I guess the whole point here is that if you do it in gimp, you add another image to the theme, thereby increasing its size. I guess rotating wouldn't be too hard to add to evas, guess I'll give it a try (mind you, as almost every other ppl in here, I've got plenty of things to do, so don't expect it any day soon.... ;) ). And, btw, having an obj rotation funct in evas could be cool, even if you don't like its use in the themes development. Lightman --------------------------------------------------------- Franz "Lightman" Marini Sys Admin and Software Analyst, Dept. of Physics, University of Milan, Italy. email : fra...@mi... --------------------------------------------------------- |
From: Chris b. R. <ch...@da...> - 2002-01-24 11:31:53
|
On Thu, Jan 24, 2002 at 11:19:57AM +0100, Christian Kreibich muttered... [snip] : : Sounds good. I wonder if we should move the menu-generating code that : scans the gnome apps over to the setup program though, so that we'd : consistently have menu dbs within e17. So two of the worksteps the setup : program would do would be scanning for kde and gnome apps... : : Christian. Good plan! Give that man a beer! -- Chris Ross (boris) [ ch...@da..., http://www.darkrock.co.uk ] [ (chris|boris)@ferite.org, http://www.ferite.org ] ""Bother," said Pooh, as the vice-squad found his GIFs." |
From: Christian K. <kre...@in...> - 2002-01-24 11:35:19
|
Chris boris Ross wrote: > > Good plan! Give that man a beer! Yes! Great idea! It would stop him from studying and make him code! :P Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Chris b. R. <ch...@da...> - 2002-01-24 11:48:13
|
On Thu, Jan 24, 2002 at 12:32:53PM +0100, Christian Kreibich muttered... : Chris boris Ross wrote: : > : > Good plan! Give that man a beer! : : Yes! Great idea! It would stop him from studying and make him code! :P </end of converstion> (we dont need the great beer debate again =P) Regards, Chris -- Chris Ross (boris) [ ch...@da..., http://www.darkrock.co.uk ] [ (chris|boris)@ferite.org, http://www.ferite.org ] ""Bother," said Pooh, as the vice-squad found his GIFs." |
From: Kevin B. <co...@co...> - 2002-01-24 12:15:24
|
Christian Kreibich wrote: > > > enl...@li... wrote: > > > > Enlightenment CVS committal > > > > Author : rephorm > > Project : e17 > > Module : apps/e > > > > Dir : e17/apps/e/src > > > > Modified Files: > > view.c > > > > Log Message: > > > > maybe we should get the prefix for gnome from gnome-config --prefix? > > Sounds good. I wonder if we should move the menu-generating code that > scans the gnome apps over to the setup program though, so that we'd > consistently have menu dbs within e17. So two of the worksteps the setup > program would do would be scanning for kde and gnome apps... Well, except that the menus won't be dynamic then, will they? Now they generate when you open them, so if you run gnome or kde and switch back to E they will always match. -- Kevin |
From: Christian K. <kre...@in...> - 2002-01-24 13:25:30
|
Kevin Brosius wrote: > > Well, except that the menus won't be dynamic then, will they? Now they > generate when you open them, so if you run gnome or kde and switch back > to E they will always match. Oh, right. Didn't think of that. Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Corey D. <cdo...@me...> - 2002-01-24 16:02:48
|
* Christian Kreibich (kre...@in...) wrote: > Kevin Brosius wrote: > > > > Well, except that the menus won't be dynamic then, will they? Now they > > generate when you open them, so if you run gnome or kde and switch back > > to E they will always match. > > Oh, right. Didn't think of that. Store the gnome prefix in a db during the setup program or something, get the string and regenerate the menus when E runs. do kde menus work similar to the gnome ones? I guess we'd need stuff to parse those too. > > Christian. > -- > ________________________________________________________________________ > http://www.whoop.org > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel __ Corey Donohoe at...@at... cdo...@me... |
From: Christian K. <kre...@in...> - 2002-01-24 18:21:55
|
Corey Donohoe wrote: > > Store the gnome prefix in a db during the setup program or something, > get the string and regenerate the menus when E runs. do kde menus work > similar to the gnome ones? I guess we'd need stuff to parse those too. The problem is that as far as I know, e17 currently generates them *once*. So when you install an app while e17 runs and you've used the menu before, it won't show up. Ideally, this should work as follows: efsd should be able to monitor directory trees. Create the gnome and/or kde menus initially when the setup program is run, or maybe the first time e17 is run. Tree-monitor the gnome and/or kde dirs when e17 is running. If the menus get modified, rebuild menus in e17. This assumes that kde also uses the fs for the menus, just as you say... Monitoring a directory tree would really help sometimes. I've been wondering about that for a while now. The problem is that it's dangerous if I just descend through the tree and monitor every directory. When using dnotify, that makes the danger of running out of file descriptors a lot more real... Btw, is it just me or have the icons vanished from the gnome menu? Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Lyle K. <te...@tw...> - 2002-01-24 20:02:56
|
* Christian Kreibich (kre...@in...) wrote: > Corey Donohoe wrote: > > Store the gnome prefix in a db during the setup program or something, > > get the string and regenerate the menus when E runs. do kde menus work > > similar to the gnome ones? I guess we'd need stuff to parse those too. > The problem is that as far as I know, e17 currently generates them > *once*. So when you install an app while e17 runs and you've used the > menu before, it won't show up. > > Ideally, this should work as follows: efsd should be able to monitor > directory trees. Create the gnome and/or kde menus initially when the > setup program is run, or maybe the first time e17 is run. Tree-monitor > the gnome and/or kde dirs when e17 is running. If the menus get > modified, rebuild menus in e17. This assumes that kde also uses the fs > for the menus, just as you say... > > Monitoring a directory tree would really help sometimes. I've been > wondering about that for a while now. The problem is that it's dangerous > if I just descend through the tree and monitor every directory. When > using dnotify, that makes the danger of running out of file descriptors > a lot more real... I haven't been following along real closely lately, but why go through all this trouble to dynamically monitor the menus while using E17? E16 does it on first run and request only, and it seems to work fine. At most, generating them on startup could be okay (but I'd want it to be configurable -- and default to off -- so that people won't complain it takes a week for E to startup, as it is E16 takes forever scanning my backgrounds). This just seems like overkill, and E17 being a rewrite, it's probably better to concentrate on getting the core features right and then getting it solid and *finished*. :) term |
From: Christian K. <kre...@in...> - 2002-01-24 22:25:22
|
Lyle Kempler wrote: > > I haven't been following along real closely lately, but why go through > all this trouble to dynamically monitor the menus while using E17? E16 > does it on first run and request only, and it seems to work fine. At > most, generating them on startup could be okay (but I'd want it to be > configurable -- and default to off -- so that people won't complain it > takes a week for E to startup, as it is E16 takes forever scanning my > backgrounds). This just seems like overkill, and E17 being a rewrite, > it's probably better to concentrate on getting the core features right > and then getting it solid and *finished*. :) Oh, totally. Like I said, personally I would put together a really basic e17 and then amaze people by releasing versions with new features every other month :) We could (and probably should) make the menus regeneratable by request first, no doubt. I was just brainstorming. You know, when I say "ideally", I usually mean "roughly 4 releases into the future" *grin*. It's one thing to talk about features, the other is making them happen. My todo list is growing on a daily basis right now... Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Carsten H. (T. R. <ra...@ra...> - 2002-01-25 00:44:08
|
On Thu, 24 Jan 2002 19:19:00 +0100 Christian Kreibich <kre...@in...> wrote: > Corey Donohoe wrote: > > > > Store the gnome prefix in a db during the setup program or something, > > get the string and regenerate the menus when E runs. do kde menus work > > similar to the gnome ones? I guess we'd need stuff to parse those too. > > The problem is that as far as I know, e17 currently generates them > *once*. So when you install an app while e17 runs and you've used the > menu before, it won't show up. > Ideally, this should work as follows: efsd should be able to monitor > directory trees. Create the gnome and/or kde menus initially when the > setup program is run, or maybe the first time e17 is run. Tree-monitor > the gnome and/or kde dirs when e17 is running. If the menus get > modified, rebuild menus in e17. This assumes that kde also uses the fs > for the menus, just as you say... > > Monitoring a directory tree would really help sometimes. I've been > wondering about that for a while now. The problem is that it's dangerous > if I just descend through the tree and monitor every directory. When > using dnotify, that makes the danger of running out of file descriptors > a lot more real... > > Btw, is it just me or have the icons vanished from the gnome menu? > > Christian. > -- > ________________________________________________________________________ > http://www.whoop.org > > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9439 |
From: Hans <han...@br...> - 2002-01-25 15:06:21
|
On Thu, Jan 24, 2002 at 07:19:00PM +0100, Christian Kreibich wrote: > Ideally, this should work as follows: efsd should be able to monitor > directory trees. Create the gnome and/or kde menus initially when the > setup program is run, or maybe the first time e17 is run. > Tree-monitor the gnome and/or kde dirs when e17 is running. And ignore changes made when e is not running? It's not a very big deal ofcourse but i kinda like when stuff is absolutely waterproof. It sounds like a great idea to monitor gnome/kde menu trees but e should generate menus on _every_ startup imo. > This assumes that kde also uses the fs for the menus, just as you > say... It does. :-) $ ls -1 /usr/share/applnk/ Applications/ Development/ Editors/ Games/ [...] $ ls -1 /usr/share/applnk/Editors/ gvim.desktop kate.desktop kwrite.desktop [...] And the spec for kdes desktop files are on this url for anyone who's interested: http://www.freedesktop.org/standards/desktop-entry-spec.html I think the structure not very different from gnome right? Maybe it's even the same. I'm not sure though. > Monitoring a directory tree would really help sometimes. I've been > wondering about that for a while now. Is there no mechanism for this in imon or dnotify? I think, once when i was toying with fam, i just added a watch on some directory and it reported changes in subdirectories also. But maybe i remember incorrectly. Somehow i think it would be best if it was handeled below efsds level anyways. But maybe that is not an option :( -- Hans |
From: Christian K. <kre...@in...> - 2002-01-25 15:58:30
|
Hans L=F6fving wrote: >=20 > > This assumes that kde also uses the fs for the menus, just as you > > say... >=20 > It does. :-) > > And the spec for kdes desktop files are on this url for anyone who's > interested: http://www.freedesktop.org/standards/desktop-entry-spec.html > I think the structure not very different from gnome right? > Maybe it's even the same. I'm not sure though. Excellent. It seems we don't need to touch a single line of code. Thanks for the info. =20 > > Monitoring a directory tree would really help sometimes. I've been > > wondering about that for a while now. >=20 > Is there no mechanism for this in imon or dnotify? No :) It seems that fam has experimental code there -- FAMMonitorCollection() -- but that is not functional. Christian. --=20 ________________________________________________________________________ http://www.whoop.org |
From: Hans <ha...@br...> - 2002-01-25 16:48:39
|
On Fri, Jan 25, 2002 at 04:55:43PM +0100, Christian Kreibich wrote: =20 > It seems we don't need to touch a single line of code. Thanks for the > info. np! > > Is there no mechanism for this in imon or dnotify? >=20 > No :) It seems that fam has experimental code there -- > FAMMonitorCollection() -- but that is not functional. Oh. :/ I see. So fam is still under development? Last time i checked it seemed to have been untouched for quite a long time. Any guesses on the timeframe for a stable(tm) release including FAMMonitorCollection() ? (it's always fun to guess release dates, right? :) So, what's decided on when to generate/update gnome/kde menus? I certainly would like to see my menus in e being constantly in sync with gnome and kdes menus which would mean scanning them on startup as well as monitoring the directory tree. But perhaps this is something for future versions. If included at all. KDE updates menus when new .desktop entries are being added in the fs but it seems to use some kind of timer that checks for changes every n seconds. Kinda boring... Hans |