2009/4/2 Dave Andreoli <d...@gurumeditation.it>
> Ok, I'm a little late on this post, I'm really busy lately, sorry :(
>
> Hey Sergey.... welcome :)
>
> Some random stuff in replay to the whole thread:
>
> * efm atm read .gtk-bookmarks (they are displayed in the new
> "file" submenu in the E main menu). This is cool, as many other
> apps use it, but at the end create some confusion with the E favorite
> folder. We need a single place to show favorites to the user.
> Note that the .favorite approach of E is much powerfull than the
> .gtk-bookmark, you can have what you want in the favorites (link to file,
> link to apps, link to device, etc) while in .gtk-bookmarks you can only
> have directory path.
> In conclusion I think the best solution is to keep the efm favorites as is
> (also with
> .desktop link to devices) and, optionally, populate it with entry (link or
> .desktop)
> from the .gtk-bookmarks file.
>
> * IMO the toolbar is a crucial point of the efm. We really need to fix it.
> It must
> handle every gadget we have, also with d'n'd, as we have many intresting
> gadgets for
> it (places, trash, efm_path, etc). As many of you said: the toolbar need to
> be placed
> also on the right or on the left, AND we should be able to have more than
> one toolbar.
> one on top and one on the left, just to make a " random " example ;)
>
> * I agree that we need to make gadget aware of the container type (shelf,
> gadcon,
> or toolbar). I remember that you can check for something like
> gadget->gadcon->name,
> but I'm not sure. This could be improved if a module have the ability to
> choose the
> accepted container, something like e_gadget_dont_show_in("toolbar")
>
> hmmm... pause... I have to much stuff to write... What about if I make a
> page on the
> wiki that we can use as TODO ? so we can keep all the progress up to date.
> I can start the page with all the question on this thread.
maybe better to use the release plan page.
>
>
> Dave
>
>
>
>
>
> 2009/4/1 Viktor Kojouharov <vkojouha...@gmail.com>
>
> On Wed, 2009-04-01 at 11:52 -0500, Nick Hughart wrote:
>> > On Wed, 1 Apr 2009 12:59:54 -0300
>> > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
>> >
>> > > On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov
>> > > <vkojouha...@gmail.com> wrote:
>> > > > On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote:
>> > > >> Hello, Dave!
>> > > >>
>> > > >> I see you importing 'places' into efm2.
>> > > >> I'm starting work on efm2 too, because i have plans for E17 use and
>> > > >> interesting first a robust, usable file manager.
>> > > >> I can help you. What tasks are remaining exactly?
>> > > >>
>> > > >> In my view there are several major improvements: removable devices
>> > > >> mount with correct fstab processing (so devices can be mounting
>> > > >> properly when fstab corresponding fstab records exists); grid
>> > > >> representation in fileman window with name, type, size, access
>> > > >> rights, etc.; toolbar in file manager window with most using
>> > > >> operations.
>> > > >>
>> > > >> What about background/color set GUI, rename in place, progress
>> > > >> indication?
>> > > > We should take the in-place to a whole new level, and remove as many
>> > > > dialogs as we can. The only dialog that should stay is the
>> > > > properties one, since it is quite big. Every other dialog should go
>> > > > as an overlay to the e_fm window that spawned it.
>> > >
>> > > problem: window can be too small.
>> > >
>> > > problem specifically to rename in place: text can grow outside the
>> > > viewport and it will be unusable. elementary suffers from that a lot,
>> > > needs to be solved somehow generically.
>> >
>> > Make the entry that shows up be scrollable. Doesn't need a scrollbar,
>> > just scroll it with the cursor. Granted this adds some complexity, but
>> > with edje_entry it might not be too hard.
>> >
>> > >
>> > >
>> > > > Some type of status overlay that displays useful info on the
>> > > > selected item (or is hidden if nothing is selected) would also be
>> > > > nice.
>> > >
>> > > yes, I'd say like a statusbar, but nicely overlayed.
>> >
>> > Anyone use evidence before? If not take a look at old screenshots.
>> > That had the sexiest info popup I've ever seen :)
>> p.s. I knew I forgot something. Speaking of evidence, people seem to be
>> begging for nautilus to have a browser view (like evidence, finder,
>> everything else under the sun). Just getting the idea out of the door.
>> Could be the first new feature after E17 goes live.
>>
>>
>> >
>> > >
>> > >
>> > > > the rest just need love and bug cleaning :)
>> > > >
>> > > >
>> > > > btw, what do you guys think if these ideas:
>> > > >
>> > > > Having a gadcon on the left/right side to display some info, like a
>> > > > directory tree or a list of favourites?
>> > >
>> > > isn't it your drawer stuff?!
>> >
>> > Also allow a way to disable this hideous convention. I'd much
>> > rather just have a pull down on the toolbar that I can pick from
>> > instead of something soaking up screen real estate. Think of the
>> > poor individuals on 320x320 touchscreens :)
>> >
>> > >
>> > >
>> > > > Using the .gtk-bookmarks instead of the current favourites (if the
>> > > > first supports things other than directories)
>> > >
>> > > I'm pro it, at least firefox and other apps would use it. However kde
>> > > apps do not share the same thing, so maybe have an option to try/use
>> > > both, as some users will just not use gtk apps.
>> >
>> > Or we could potentially work with the KDE team, as they've expressed
>> > their distaste for some of the current specs as well, to generate a
>> > proper standard and f*** Gnome? Once Gnome no longer inter-operates with
>> > anything, maybe they'll get the point that they can't control the Linux
>> > desktop :)
>> >
>> > >
>> > >
>> > > > Using a toolbar to open different locations within the same e_fm
>> > > > window?
>> > >
>> > > that's efm_nav, no?
>> >
>> > I'm thinking he meant more of a paned typed thing where you can have
>> > multiple views all in a single window. Don't think this will be making
>> > it into E17 if that's the case.
>> >
>> > >
>> > >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > _______________________________________________
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
