Re: [E-devel] eflpp + ewl + ecmd

[fuscated]

Hello,

I'm sorry for the delay, but I wanted to reach my 0.1 milestone.
Here is the link for the source of my ECommander application:

http://smrt.is-a-geek.org/ecmd/ (screenshots + source)

ECommander (ecmd) is a 2 pane file manager similar to all other
commanders (total/nortan/midnight/gnome). It has the basic operations
implemented (CAUTION: it is possible that some files can be
lost/deleted!!!) and more is to come. See the README for info how to
build and use it. (Sorry that there is no autotools config, I could
grasp it:(). For a successful build you need to apply my c++ patch to
efreet.

The application is written in c++ and uses ewl as the widget toolkit.
I've written a wrapper for ewl, to make my life easier.:) 
The wrapper is 30-50% complete. I've wrapped only widgets I've used.
I hope the interested in ewl will give me some constructive crituque,
so I can improve it.
At the moment there are some problems with the wrapper:
1. The widget class has one ewl::function (boost,tr1,c++0x function
class) member per possible callback, no matter if the callback is used.
2. You can have only one callback functions attached to a given type
of callbacks for the widget
3. The mvc wrapping is a bit messed up.
4. some more I can't remember :)

Any suggestions how to fix these issues are welcome :)

Best regards,
Teodor Petrov


On Wed, 31 Dec 2008 09:34:09 +0100
Andreas Volz li...@brachttal.net wrote:

 Am Sun, 21 Dec 2008 18:11:15 +0200 schrieb fusca...@gmail.com:
 
  I'm using c++ and ewl to write a filemanager app and I think I'll use
  eet for the configuration files. I've also done an ewl c++ wrapper
  (not complete at all). And I can contribute the code to eflpp when it
  is more complete.
 
 I just started to wrap ETK as you see with my last commit. In parallel
 I liked to start with EWL. But if you yet work on it we may share our
 work. But the EWL wrapper you do has to fit the eflpp design. How far
 did you proceed? Could you show something?
 

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] efreet c++ patch

[fuscated]

Hello,

Here is a patch for efreet that make it work when used from c++ programs.
I'm not sure if it is correct, but hope someone with C knowleage will 
correct it if needed.

Best regards,
Teodor Petrov

p.s. link to the patch http://pastebin.ca/1321183
p.p.s. and the patch below

Index: src/lib/efreet_utils.h
===
--- src/lib/efreet_utils.h  (revision 38574)
+++ src/lib/efreet_utils.h  (working copy)
@@ -2,23 +2,24 @@
 #ifndef EFREET_UTILS_H
 #define EFREET_UTILS_H
 
-typedef enum Efreet_Desktop_Change Efreet_Desktop_Change;
 
-enum Efreet_Desktop_Change
+enum Efreet_Desktop_Change_
 {
 EFREET_DESKTOP_CHANGE_ADD,
 EFREET_DESKTOP_CHANGE_REMOVE,
 EFREET_DESKTOP_CHANGE_UPDATE
 };
+typedef enum Efreet_Desktop_Change_ Efreet_Desktop_Change;
 
-typedef struct Efreet_Event_Desktop_Change Efreet_Event_Desktop_Change;
 
-struct Efreet_Event_Desktop_Change
+struct Efreet_Event_Desktop_Change_
 {
 Efreet_Desktop *current;
 Efreet_Desktop *previous;
 Efreet_Desktop_Change change;
 };
+typedef struct Efreet_Event_Desktop_Change_ Efreet_Event_Desktop_Change;
+
 
 EAPI int efreet_util_init(void);
 EAPI int efreet_util_shutdown(void);
Index: src/lib/efreet_desktop.h
===
--- src/lib/efreet_desktop.h(revision 38574)
+++ src/lib/efreet_desktop.h(working copy)
@@ -19,7 +19,9 @@
 /**
  * Efreet_Desktop_Type
  */
+/*
 typedef enum Efreet_Desktop_Type Efreet_Desktop_Type;
+*/
 
 /**
  * Efreet_Desktop

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efreet mime default application patch

[fuscated]

On Tue, 4 Nov 2008 11:01:10 +1100
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote:

 On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli [EMAIL PROTECTED]
 babbled:
 
   1. config everyone cal look at
   OR
   2. opening service. e.g. a dbus call- u send an array (list) of file
   paths
   and say open them please - e will open them for you. this way you
   also
   recycle the exec method and child process tracking etc. if the target
   file is a
   directory - it opens a directory window, etc.
   
   is #2 perhaps not better?
  
  The #2 is powerfull but will work only if E is running, and this is bad
  for applications, that should work also outside E. 
  
  I prefer the #1, put the config where everyone can look...what about
  the defaults.list file ? ;) (it's not yet a fdo standard, but it's a 
  simple and clear way to store the info)
 
 technically - any app/desktop/wm could provide the same dbus service... a
 stand-alone app could too. the problem with #1 is that if e decides to change
 config, format, versioning, keys, break it etc. every app is stuck catching 
 up.
 putting it into a lib and formalising it sets the config in stone as u cant go
 change it as u are going to break format/api. a very limited config is
 possible, but i think it's a bit premature to go formalising this - for e it 
 is
 i think. also this means the config now can't use e's normal config schemes.
 

Hello,
I'll speak here as a future user of that API/lib. 
I'm writing a *-commander(2-pane) style file manager in Ewl.
I've the basic operations ready: browsing/copy/delete/new dir/rename,
now I have to implement the open file operation.
I have wide range of posibilities:
1. Implement my own api:
   a. 100% custom way of matching executables to files
   b. copy the code from efm
   c. copy and adapt the patch in my app
(I don't like all three choices here. They are hard to implement. Do
something that has been done already. Breaks the integration in the
desktop. And all code should be redone N-time when there is a
specification).
2. Try to convince you that any API/lib is better that no lib.
   Here are the pros and cons of the API (as I sees them):
   Pros:
 Ease of use
 No code duplication
 If a spec is released all apps will be conformant to that spec.
 If the spec requires an API change all apps should be fixed, 
 this way all will be conformant.
 All apps in E will behave the same.
   Cons:
 Current apps should be ported to the API
 The API might be to restrictive for some apps
 raster wrote:
 also this means the config now can't use e's normal config schemes.
 I don't know what this schemes are used for, but that's a problem, too.
 Breaking the API will break all dependand on it.

I'm not too concerned with the last one, because that won't happen too
often anyway. And the requirements to the api are simple, so it will be
a simple API. If the spec says that the implementation should be
different than the current one, or someone decide that the current
implementation can be improved in some way the API won't change
drastically (It's role is to abstract the implementation, after all).

I hope that there will be made a decision that will be good for all of us.

Best regards,
Teodor Petrov


p.s. Is there an EFL way to get the list of all mime type and a list of all 
desktop files?



 -- 
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
 
 
 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
 Build the coolest Linux based applications with Moblin SDK  win great prizes
 Grand prize is a trip for two to an Open Source event anywhere in the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel