« Return to Thread: On screen text display high level method proposal

Re: On screen text display high level method proposal

by Andrea Viarengo :: Rate this Message:

Reply to Author | View in Thread

Christian Walther <cwalther <at> gmx.ch> writes:

> An idea that just occurred to me: would it make sense to put such
> features that are implemented on top of Pipmak's (public) core
> functionality into a separate namespace, maybe "pipmaklib" or something,
> instead of "pipmak"? We could conceivably end up with hundreds of them,
> and the pipmak table would be a bit crowded then.

You mean that we have to call the method:
pipmaklib.displaytext{..}

For me it's ok, (just a little long to write...)

We can put here macro-functions builded on base functionalities:
is this your idea?

I think that at this point, we have to make some thought about a
more sophisticated library/plugin system to make Pipmak more modular...

I do not know if you gave a look to the wiki page "Pipmak Library Project"
which I have written some time ago...
All that things (for the moment there are only color lib published)
should be suitable to become pipmaklib....

For example, what are you thinking about this:

a folder called lib or plugin or something like at the level of pipmak.exe
inside the folder we put files with extension .pipmaklib
which are .zip renamed like "Pipmak Resource"

each pipmaklib file have an own default.lua and own nodes and resources,

On open project, pipmak scans the folder and load every
default.lua inside the pipmaklib files and load new pipmaklib functions
that use own nodes and resources included into .pipmaklib files

In this manner we can create a lot of modules/plugins and
it should be sufficient only copy to the lib folder to make
available new features build on basic pipmak API, without the need to
modify "Pipmak Resources" or act some pipmak.dofile...or add other
nodes/resource to the project.

The first problem which I see is the numbering of the nodes...
Because every pipmaklib (potentially made by different people)
should be have an own numbering system
(ie.: every lib could have a node number 1)
We have to modify node numbering introducing global or local or
absolute or relative numbering or other ... I don't known....

What do you think?

> Could you transform your descriptions into something that fits into
> Reference.tex? Otherwise the commit will have to wait until I get around
> to doing that. (I'm trying to take a hard stance on this - no feature
> committed without documentation, otherwise it will never get written.)

I'm not an expert of tex... I will try...
You use some visual tool to write doc, or you use just a text editor?

> Small bug: weird things happen with the positioning of the text when the
> window is resized while the demo is running. Do you think this can be
> fixed in a reasonable way?

I will check it

> I haven't scrutinized the code very thoroughly, but a few detail
> comments nonetheless:
>
> > --   Globals defined:
> > --      pipmak.cachedtext      (table)
> > --      pipmak.istextdisplayed (boolean)
>

I would like to don't use any globals....but I need to store the cache
of the messages from a displaytext call and the next, this need only
until the overlayed node is displayed (when the overlay is closed,
the cache is empty)
If you have other ideas, I will be happy to use them.

>
> > panel { pipmak.newimage( pipmak.screensize()) }
>

I will try your suggestions...

Bye

-Andrea




-------------------------------------------------------------------------
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=100&url=/
_______________________________________________
Pipmak-Users mailing list
Pipmak-Users@...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users

 « Return to Thread: On screen text display high level method proposal