Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFGUI (old thread)  (Read 85819 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFGUI (old thread)
« Reply #45 on: May 31, 2010, 11:17:50 pm »
The macro is not really an option, it would fail for example for multiple class that have the same name but in different scopes (namespaces) :P

To use the preprocessor like this you'd need the fully qualified name, which means using it outside the class definition. It's technically possible with some tricks, but I think that defining the virtual function manually is the simplest solution.
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #46 on: May 31, 2010, 11:45:02 pm »
Quote from: "Nexus"
When all C++ compiler and runtime abstraction facilities fail, there's still the preprocessor to save you. :)

Indeed, but I don't think something like "ClassName()" is necessary. When serialization is delegated to the widgets themselves, I think it's perfectly fine when they throw a class name string to the storage driver themselves (they do so for properties (which are specific and can't be read by an abstract class because they're unknown) so they can for a class name).

Okay, should better have quoted Ceylo in this case -- just too lazy to look for the proper post. ;)


Quote
By the way, Tank, if you have already used Boost, might not the library Boost.Serialize be an option? At least, it contains some interesting concepts.

Boost.Serialization would be incredible great, but that means an extra dependency. You're right, I'm using some components of Boost, but those are header-only, which means no building on target systems is necessary that makes distribution easy.

I think I'll go with a selfmade and lightweight serialization solution. However, I still have to think about the design and do some tests if that'll work out and -- more importantly -- will make the whole thing easier or not (regarding to usage *and* design).

@Ceylo:
The code looks good, but I'd choose another approach. However the concept is at least similar to yours. :) Thank you.


I'm glad that some other experienced guys are following this thread. I repeat myself, but: I'm always open for opinions. ;)

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
SFGUI (old thread)
« Reply #47 on: June 01, 2010, 01:45:16 am »
Quote from: "Tank"
Quote from: "Nexus"
When all C++ compiler and runtime abstraction facilities fail, there's still the preprocessor to save you. :)

Indeed, but I don't think something like "ClassName()" is necessary. When serialization is delegated to the widgets themselves, I think it's perfectly fine when they throw a class name string to the storage driver themselves (they do so for properties (which are specific and can't be read by an abstract class because they're unknown) so they can for a class name).

Okay, should better have quoted Ceylo in this case -- just too lazy to look for the proper post. ;)

Mmmh.. I don't understand what you mean with "it's perfectly fine when they throw a class name string to the storage driver themselves". The attributes are only know from the widget itself and that's fine. But here the class name was used by the "runtime" to find which serializer should be used (by the way, the class name should fully represent the class : something like sfg.widget.control.samplewidget...).


Quote from: "Tank"
I think I'll go with a selfmade and lightweight serialization solution. However, I still have to think about the design and do some tests if that'll work out and -- more importantly -- will make the whole thing easier or not (regarding to usage *and* design).

@Ceylo:
The code looks good, but I'd choose another approach. However the concept is at least similar to yours. :) Thank you.

Thus a third solution ?
Want to play movies in your SFML application? Check out sfeMovie!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFGUI (old thread)
« Reply #48 on: June 01, 2010, 08:25:30 am »
What about using a metaobject system similar to Qt? A widget would declare all of its properties, then you can request and manipulate them at runtime. It allows a kind of reflection actually.

This system is much more powerful than a "hard-coded" serialization solution, because the meta-properties can then be used anywehere:
- text serialization
- object editor tree
- binding your classes to a script engine
- ...
- look at the huge list of Qt modules based on the meta-object system

If you're interested, I know a very good library which does exactly that, much better than Qt (no precompiler, uses meta-programming to generate the bindings at compile-time, only requires boost headers).
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #49 on: June 01, 2010, 03:33:07 pm »
Quote
But here the class name was used by the "runtime" to find which serializer should be used

Okay sorry, I misread your post then. Indeed this wouldn't be really different from the current approach. I don't think it would simplify the serialization process -- it'd just be placed somewhere else.

The main problem with a "Serializable" interface is that it'll be a pain to get the widgets that can be serialized and those which can't (because some maybe don't implement "Serializable"). A solution would be to provide a virtual method in sfg::Widget, so that all widgets have at least the same interface. But I don't like this idea much, just because it forces every widget to implement a (de)serialization method, thus putting in more complexity.

Quote
What about using a metaobject system similar to Qt? A widget would declare all of its properties, then you can request and manipulate them at runtime. It allows a kind of reflection actually.
...
If you're interested, I know a very good library which does exactly that, much better than Qt (no precompiler, uses meta-programming to generate the bindings at compile-time, only requires boost headers).

I've never heard of a metaobject system, but I was at least thinking about something similar to be able to access widget's properties more generic. So your idea sounds perfect in my ears. :) Would be nice to hear from that library to see how it works in detail. I guess it would perfectly fit into the (de)serialization process for SFGUI (at least a much cleaner design).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFGUI (old thread)
« Reply #50 on: June 01, 2010, 04:04:50 pm »
Quote
Would be nice to hear from that library to see how it works in detail. I guess it would perfectly fit into the (de)serialization process for SFGUI (at least a much cleaner design).

It's an open-source library that I wrote for my company last year. We recently switched to LGPL and made the first public release. We're still working on the website so I can't give you a link, however you can already have a look at the git repository, and I can send you the latest version (with precompiled libs, doc, etc.) if you want.

The website should be online in a few days though.

Don't hesitate to ask me if you need help or more information :)
Laurent Gomila - SFML developer

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
SFGUI (old thread)
« Reply #51 on: June 01, 2010, 04:35:43 pm »
Quote from: "Laurent"
What about using a metaobject system similar to Qt? A widget would declare all of its properties, then you can request and manipulate them at runtime. It allows a kind of reflection actually.

This system is much more powerful than a "hard-coded" serialization solution, because the meta-properties can then be used anywehere:
- text serialization
- object editor tree
- binding your classes to a script engine
- ...
- look at the huge list of Qt modules based on the meta-object system

If you're interested, I know a very good library which does exactly that, much better than Qt (no precompiler, uses meta-programming to generate the bindings at compile-time, only requires boost headers).

Does it allow to bind "function names" to "functions" ? I mean... it'd be nice to be able to set the widgets slots according to what the user set in the UI designer. Thus he wouldn't have to set these programmatically.
Want to play movies in your SFML application? Check out sfeMovie!

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #52 on: June 01, 2010, 04:41:31 pm »
Thank you very much Laurent, I'm cloning the repository right now.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFGUI (old thread)
« Reply #53 on: June 01, 2010, 04:45:25 pm »
Quote
Does it allow to bind "function names" to "functions" ? I mean... it'd be nice to be able to set the widgets slots according to what the user set in the UI designer. Thus he wouldn't have to set these programmatically.

It allows to bind functions so that you can manipulate them by their name, yes. So you could connect signals and slots in the designer and export your setup, if that's what you mean.
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #54 on: June 01, 2010, 04:57:47 pm »
At first thanks a lot for the pointer, Laurent.

Just built the library and read the example in the Doxygen documentation. I have to admit that it looks very promising and would definitely help in the (de)serialization task. I will play around a bit with it to see how it'll work out.

I'm just not sure if I should really take the extra dependency (which would of course be shipped with SFGUI) into SFGUI. But I'll definitely have a look.

Amusingly CAMP reminds me a lot of Python. :)

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
SFGUI (old thread)
« Reply #55 on: June 04, 2010, 07:28:17 pm »
Quote from: "Laurent"
Quote
Does it allow to bind "function names" to "functions" ? I mean... it'd be nice to be able to set the widgets slots according to what the user set in the UI designer. Thus he wouldn't have to set these programmatically.

It allows to bind functions so that you can manipulate them by their name, yes. So you could connect signals and slots in the designer and export your setup, if that's what you mean.

Yup that's what I was thinking of, sounds great! Thanks :)


Otherwise some news from the front* Tanks ?



*I dunno whether you say that phrase in English :/
Want to play movies in your SFML application? Check out sfeMovie!

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #56 on: June 05, 2010, 11:19:42 pm »
I dunno either, but I got the point. ;)

Yeah, I'm currently testing out some ideas for the serialization, but nothing concrete. I'll have something to test the next days, I guess.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFGUI (old thread)
« Reply #57 on: June 14, 2010, 04:07:08 pm »
Hi

Just an update about CAMP: today we published the website, forum and version 0.7.0.

http://dev.tegesoft.com/projects/camp
http://dev.tegesoft.com/projects/camp/forum/
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #58 on: June 16, 2010, 08:52:53 am »
Thank you for the pointer. I guess CAMP will make it into the first release -- and interested folks may now listen carefully -- which takes up some time. ;) (sometimes it seems that SFGUI is a neverending construction site, it was about to be released 4-5 times in the past ;))

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
SFGUI (old thread)
« Reply #59 on: June 16, 2010, 06:15:10 pm »
Quote from: "Tank"
(sometimes it seems that SFGUI is a neverending construction site, it was about to be released 4-5 times in the past ;))

Don't worry, it's always like that. Take your time :)
Pluma - Plug-in Management Framework