On 1/4/06, mista <[EMAIL PROTECTED]> wrote: > > > ok, the other thing I realized is that a greater TILE_SIZE solves the > problem that, > if you scroll up with keys, the viewport sometimes get not updated and > the selected icon is then not more visible. >
we will have to look into this in detail. > > -usability changes, like having dirs shown first, > can you turn this into an option or a sort mode? > renaming can be applied with enter and denied with escape, > good. > icon-menu has a submenu with eaps(and their respective icons) that can > open this filetype, this gets only generated once for each type, the > first time the menu shows up and is afterwards hashed. > good, we will have to integrate it into efm's mime system. for now, we do not want something that is efl-wide. we just want a part of efm's configs to map extentions to application names. once thats done and other bugs are ironed out, we can talk to Chaos and others and try to get something working across all of the EFL. > scroll with band-selection and remember selected files that are not more > visible. I had to change icon_canvas, so that icon_pack return the > coordinates where the icon is placed and let selections_rect_add work > with these coords. > good. > dnd works for single files(to drop files into other apps I put an ugly > sleep(1) in e_drag_end). > I have the problem, that the e_dnd_cb_mouse_up still gets called after > the drop is done. Is this a known bug? > I am not sure about this, maybe Chaos can give in some input about this as he has also done XDND using ecore_x? > -logical grouping changes in key_down_cb and key_select_-functions, > which reduces the size and is much better to read, as I think. for > example in key_down_cb is one section for each state typebuf_shown, > _not_shown and renaming. > I attached a snippet of the key_select functions, as they solve the > problem of flickering selections if one is already at the end in that > direction. > good. > - and some code convenience changes like wrapping the often used > ext = strrchr(file->name, '.'); > if (!ext) return 0; > if (strcasecmp(ext, ".eap")) > return 0; > with: e_fm_file_has_mime(file,"eap") > good. > One extra functionality that is working is mime lookup via libmagic, > this is also comfortable for files without extension, but if one > extension is recognized it gets hashed - so you just need to add the > mimetypes manually if the type could not be found by libmagic or the > found one is not to your liking. > this is nice, but does this require that E links against libmagic? I believe so, and hence we cant include it in Efm right now. > > if this information can be used by other e-applications then this is for > sure a better solution. refer to my comment above about this subject. > Though my version allows easy reuse of mimetype definitions > in .desktop-files, as e17genmenu can be tweaked with little effort to > put this information in the eap. > What about reading the information once from the eap to store them in > the eet-config? > Can you elaborate please? All the items marked with "good" seem worthy of inclusion with-in Efm. Could you port them to work with-in Efm and generate a patch for review? Best regards, hisham. -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
