Project plans 2007

[Bo Lorentsen]

Hi ...

Just to let anyone know, I am waiting for Auke's approval for my current
contribution of code to XFC project, and when or if he approved this I
have the following plans for XFC :

  * Make a libXFCsourceview (in my source tree now)
  * Make debian packages
  * Optimize signal system even more (I have some ideas to try)
  * Fix bug's I or other encounter using XFC.
  * See if the TreeIter can be modeled to hold the model itself.

Any other good ideas ?

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Brian J. Tarricone]

Bo Lorentsen wrote:

> Hi ...
>
> Just to let anyone know, I am waiting for Auke's approval for my current
> contribution of code to XFC project, and when or if he approved this I
> have the following plans for XFC :
>
>   * Make a libXFCsourceview (in my source tree now)
>   * Make debian packages
>   * Optimize signal system even more (I have some ideas to try)
>   * Fix bug's I or other encounter using XFC.
>   * See if the TreeIter can be modeled to hold the model itself.

Cool!

> Any other good ideas ?

How about wrapping libxfce4util, libxfcegui4, and libxfce4panel?
Perhaps also libexo, libthunar-vfs, and libthunarx?  (Don't bother with
libxfce4mcs; hopefully it'll be gone by 4.6.)

        -brian


_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Brian J. Tarricone wrote:

 >> Any other good ideas ?

 > How about wrapping libxfce4util, libxfcegui4, and libxfce4panel?
Hmm, I guess I expected this, a libXFCxfce would be natural for a C++
framework hosted on the Xfce site :-) But I need gain some understanding
  (and motivation :-)) before doing this.

How many developers would use this, do you think, and what kind of new
applications will this open up for ?

 > Perhaps also libexo, libthunar-vfs, and libthunarx?  (Don't bother with
 > libxfce4mcs; hopefully it'll be gone by 4.6.)

I think I need to understand more about Xfce before I know what this
really is.

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Brian J. Tarricone]

Bo Lorentsen wrote:
> Brian J. Tarricone wrote:
>
>>> Any other good ideas ?
>>
>> How about wrapping libxfce4util, libxfcegui4, and libxfce4panel?
>
> Hmm, I guess I expected this, a libXFCxfce would be natural for a C++
> framework hosted on the Xfce site :-) But I need gain some understanding
>   (and motivation :-)) before doing this.

IIRC, Jeff's original idea was to expand libXFCcore to include
libxfce4util and libXFCgui to include libxfcegui4.  I guess that's up to
you, though.  Wrapping the Xfce libs in a separate library would make it
easier for people to only depend on the core gtk/gdk/glib wrappers if
that's all they want/need.

> How many developers would use this, do you think, and what kind of new
> applications will this open up for ?

As an Xfce developer, the lack of this is really the only thing that's
keeping me from using XFC at present (frankly, I'm getting sick of
writing GUI stuff in plain C, if for no other reason than all the
redundant typing and inelegant class casts).  I've come to rely on a lot
of the utility stuff in the libxfce* libraries, and using them for a few
purposes (XfceAboutDialog, XfceTitledDialog, etc.) generally makes apps
more "Xfce-ish".

Wrapping libxfce4panel would let people write xfce4-panel plugins in C++
'natively'.

On a side note, I'd like to see XFC to become something more than "just
another gtkmm".  Yes, I'm aware that XFC and gtkmm are designed quite a
bit differently under the hood, and using them can be very different in
certain circumstances... but appearances do matter as well.

>> Perhaps also libexo, libthunar-vfs, and libthunarx?  (Don't bother with
>> libxfce4mcs; hopefully it'll be gone by 4.6.)
>
> I think I need to understand more about Xfce before I know what this
> really is.

These are more optional - libthunar-vfs is a file-manager-oriented VFS
layer and libthunarx is a pluggable extension library for thunar.  There
probably aren't too many apps that could/would make use of these.
libexo, however, is designed as more of an app-building utility toolkit
(i.e., of greater scope than the more desktop-component-oriented
libxfce4util/libxfcegui4).

        -brian

_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Brian J. Tarricone]

Brian J. Tarricone wrote:

> IIRC, Jeff's original idea was to expand libXFCcore to include
> libxfce4util and libXFCgui to include libxfcegui4.

Correction: Jeff's FAQ list indicates he was planning on wrapping the
libxfce* stuff in 'libXFCde'.  So that's consistent with your initial
suggestion.

        -brian

_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Brian J. Tarricone wrote:
>
> IIRC, Jeff's original idea was to expand libXFCcore to include
> libxfce4util and libXFCgui to include libxfcegui4.  I guess that's up to
> you, though.  Wrapping the Xfce libs in a separate library would make it
> easier for people to only depend on the core gtk/gdk/glib wrappers if
> that's all they want/need.
Ok, Jeff's goals fits nicely to Xfce's, but I still like to be able to
write "Gtk+2" apps that is not necessary bound to Xfce. But I don't
think that is going to be a big issue anyway.

> As an Xfce developer, the lack of this is really the only thing that's
> keeping me from using XFC at present (frankly, I'm getting sick of
> writing GUI stuff in plain C, if for no other reason than all the
> redundant typing and inelegant class casts).  I've come to rely on a lot
> of the utility stuff in the libxfce* libraries, and using them for a few
> purposes (XfceAboutDialog, XfceTitledDialog, etc.) generally makes apps
> more "Xfce-ish".
Hmm, where would you suggest its best to start, what would be the most
helpfull part to start wrapping ? Have you any idea how to structure
this, or are we "just" expanding with some new Xfce specific Gtk+
widgets (like I have done in my sourceview expansion) ?

> Wrapping libxfce4panel would let people write xfce4-panel plugins in C++
> 'natively'.
But this may not be the most important task to start with, right ?

> On a side note, I'd like to see XFC to become something more than "just
> another gtkmm".  Yes, I'm aware that XFC and gtkmm are designed quite a
> bit differently under the hood, and using them can be very different in
> certain circumstances... but appearances do matter as well.
In what way do you like XFC to not be "just another gtkmm" ? Could You
be a bit more specific ?

> These are more optional - libthunar-vfs is a file-manager-oriented VFS
> layer and libthunarx is a pluggable extension library for thunar.  There
> probably aren't too many apps that could/would make use of these.
> libexo, however, is designed as more of an app-building utility toolkit
> (i.e., of greater scope than the more desktop-component-oriented
> libxfce4util/libxfcegui4).
I am sure that if we find a solid structure for these extensions, there
will be basis for many possibilities. The only problem is ... I need to
do some reading :-)


/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Brian J. Tarricone wrote:
>
> Correction: Jeff's FAQ list indicates he was planning on wrapping the
> libxfce* stuff in 'libXFCde'.  So that's consistent with your initial
> suggestion.
Ahh, that makes sense ... except for the name as I think libXFCe would
be more correct :-)

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Sriram Durbha]

my suggestion : making XFC one single entity .
instead of having to download twoor three different pieces and compiling them, it woul dbe much better if it were like Qt, just one source ball to get and build.
this would help immensely to attract more people to try it. 
it is easy for us to say    "c'mon if you want to develop software, cant you put up with one or two additional downloads? this is what you will be doing a lot of any way!!"
But the fact is that beginners prefer to focus their attention on learning to use the library to get their simple apps done.  Once they are comfortable, they can move to other things.. including complex builds with active dependency tracking.
cheers
ram

On 12/11/06, Bo Lorentsen <bl@...> wrote:

Brian J. Tarricone wrote:
>
> Correction: Jeff's FAQ list indicates he was planning on wrapping the
> libxfce* stuff in 'libXFCde'.  So that's consistent with your initial
> suggestion.
Ahh, that makes sense ... except for the name as I think libXFCe would
be more correct :-)

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Sriram Durbha wrote:

> my suggestion : making XFC one single entity .
> instead of having to download twoor three different pieces and compiling
> them, it woul dbe much better if it were like Qt, just one source ball to
> get and build.
Agree, this is my plan too, and what Jeff has started doing.

But inside this "chunk of code" or tar ball comes different libraries,
like core, ui, glade and now sourceview. The reason for this is to make
it easy to build the lib with different abilities.

When putting this into deb packages, its much more easy to make small
packages like the ones Xfce4 uses in Debian.

> But the fact is that beginners prefer to focus their attention on learning
> to use the library to get their simple apps done.  Once they are
> comfortable, they can move to other things.. including complex builds with
> active dependency tracking.
I agree, it is a good thing to focus on, an I still plan to have XFC to
be one big tar ball and one big build, but I also hope the deb files to
be more specific.

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bo Lorentsen wrote:
> Brian J. Tarricone wrote:
>> Correction: Jeff's FAQ list indicates he was planning on wrapping the
>> libxfce* stuff in 'libXFCde'.  So that's consistent with your initial
>> suggestion.
>
> Ahh, that makes sense ... except for the name as I think libXFCe would
> be more correct :-)

No, 'libXFCe' is just confusing.  The idea was 'de' = 'desktop environment'.

        -brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFftdZ6XyW6VEeAnsRAszQAKCyFaA28vLhjeCvebQETJCGtGguAwCeIYXm
JqXT030CIlydFSxu7Tqo3OI=
=vB9F
-----END PGP SIGNATURE-----
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Brian J. Tarricone wrote:

> No, 'libXFCe' is just confusing.  The idea was 'de' = 'desktop environment'.
Guess you are right :-)

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev