Linux GUI packaging question

Hi All,

I'm sorry but I think I asked the wrong question or at least asked it the wrong way.  The more I think about it the more I realize it isn't even that much about packaging and more about the choice of the class for the display window.  That is why I'm not sure it is a window.  I guess I'm looking for some kind of display class.  Once I can settle on that, the packaging questions become easer.  Knowing the display class dictates what else gets loaded and maybe that will dictate the packaging instructions class (what gets sub classed to drive the packaging). 

To recast the question, what is the best class for this kind of display?  I need to display a picture, draw things like lines, numbers and letters on the picture, in a non-permanent way, meaning they move over the picture with out leaving artifacts.

Thanks for any ideas.

Lou

On Wednesday, October 31, 2018 at 10:41:34 AM UTC-4, Louis LaBrunda wrote:

Hi Guys,

I'm working on a program targeted for the Raspberry Zero running the full GUI version of Raspbian.  That said, I don't consider this a Raspberry question but a Linux GUI packaging question.  I'm not at the packaging stage yet but what I intend to do is odd enough that I want to start thinking about packaging and get as many ideas about it as I can.

The program will display pictures on the screen.  There will be no mouse or keyboard support.  Instead, control of the program will be via the same kind of Seaside interface as my RaspberryRelay program that I have posted about and demonstrated here.

Normally when packaging a GUI program the main window is the focus of the packaging and the resultant image and executable.  Also, normally when packaging a Seaside program (headless), one picks a class to get things started and that is sort of the focus of the packaging.  Just an image is created and the supplied headless executable is used.

I think I'm going to need to use the X version of the executable (es on Raspbian) but an executable of the same name as the program is not needed as no one is going to be double clicking on it.  This brings me to another question.  The "main window" is not a main window in the normal sense.  It is for display only.  What is being displayed will change but the viewer doesn't key anything in or use a mouse.  Do I need a "normal" window or is there something else I can use.  I think I have seen classes that are not normally considered part of a GUI app and can be loaded in a headless image for popup messages to some console (I may be wrong about this).  Can anyone point me in the right direction for the screen display class.

Should the screen display class be the focus of packaging and therefor the start of the program and then it starts the Seaside stuff or the other way around?

Lou

Hi Richard,

Between the time I posted the question and now I remembered the Cg classes and started playing with them.  Not much progress yet and unfortunately they don't seem to work the same on Linux as windows.  On windows I can draw on the screen, it only stays until windows refreshes the screen but it is a place to start.  On Linux, the same code doesn't seem to draw anything.

Thanks for the answer and anything else you think of.

Lou

On Wednesday, October 31, 2018 at 8:33:46 PM UTC-4, Richard Sargent wrote:

On Wednesday, October 31, 2018 at 12:52:47 PM UTC-7, Louis LaBrunda wrote:

Hi All,

I'm sorry but I think I asked the wrong question or at least asked it the wrong way.  The more I think about it the more I realize it isn't even that much about packaging and more about the choice of the class for the display window.  That is why I'm not sure it is a window.  I guess I'm looking for some kind of display class.  Once I can settle on that, the packaging questions become easer.  Knowing the display class dictates what else gets loaded and maybe that will dictate the packaging instructions class (what gets sub classed to drive the packaging). 

To recast the question, what is the best class for this kind of display?  I need to display a picture, draw things like lines, numbers and letters on the picture, in a non-permanent way, meaning they move over the picture with out leaving artifacts.

You might want to look at the low-level Cg classes. I don't have an image open in front of me, so I am going by memory.

I think there is a CgDisplay class which represents the entire display surface. There are also various bitmap classes (or similar) which you can render on and then display one on the display surface while preparing the next one, etc.

The Gc stuff is pretty low-level, but if you're not trying to build an ABT components view, it may be enough. Perhaps the Common Widgets layer would be the better place, but it might be biased toward an overlapping windows UI and have too many impediments for what you are trying to do.

Thanks for any ideas.

Lou

On Wednesday, October 31, 2018 at 10:41:34 AM UTC-4, Louis LaBrunda wrote:

Hi Guys,

I'm working on a program targeted for the Raspberry Zero running the full GUI version of Raspbian.  That said, I don't consider this a Raspberry question but a Linux GUI packaging question.  I'm not at the packaging stage yet but what I intend to do is odd enough that I want to start thinking about packaging and get as many ideas about it as I can.

The program will display pictures on the screen.  There will be no mouse or keyboard support.  Instead, control of the program will be via the same kind of Seaside interface as my RaspberryRelay program that I have posted about and demonstrated here.

Normally when packaging a GUI program the main window is the focus of the packaging and the resultant image and executable.  Also, normally when packaging a Seaside program (headless), one picks a class to get things started and that is sort of the focus of the packaging.  Just an image is created and the supplied headless executable is used.

I think I'm going to need to use the X version of the executable (es on Raspbian) but an executable of the same name as the program is not needed as no one is going to be double clicking on it.  This brings me to another question.  The "main window" is not a main window in the normal sense.  It is for display only.  What is being displayed will change but the viewer doesn't key anything in or use a mouse.  Do I need a "normal" window or is there something else I can use.  I think I have seen classes that are not normally considered part of a GUI app and can be loaded in a headless image for popup messages to some console (I may be wrong about this).  Can anyone point me in the right direction for the screen display class.

Should the screen display class be the focus of packaging and therefor the start of the program and then it starts the Seaside stuff or the other way around?

Lou

Lou,

this may be completely stupid, but what I seem to read in your question is that you are looking for a way to open a window without any decorations covering the whole screen. This is where you want to display images in. 

At least that is what I'd start with: how do I open a Window in X which has the screens' size and what is needed in X Windows to make it not have a title, resize handles and such.

One question, though, that I see unanswered even if you find a solution to these: how do I keep a user from switching between windows/programs...? This requires digging into X windows much deeper than I'd like... ;-)

Joachim

Am Donnerstag, 1. November 2018 02:27:04 UTC+1 schrieb Louis LaBrunda:

Hi Richard,

Between the time I posted the question and now I remembered the Cg classes and started playing with them.  Not much progress yet and unfortunately they don't seem to work the same on Linux as windows.  On windows I can draw on the screen, it only stays until windows refreshes the screen but it is a place to start.  On Linux, the same code doesn't seem to draw anything.

Thanks for the answer and anything else you think of.

Lou

On Wednesday, October 31, 2018 at 8:33:46 PM UTC-4, Richard Sargent wrote:

On Wednesday, October 31, 2018 at 12:52:47 PM UTC-7, Louis LaBrunda wrote:

Hi All,

I'm sorry but I think I asked the wrong question or at least asked it the wrong way.  The more I think about it the more I realize it isn't even that much about packaging and more about the choice of the class for the display window.  That is why I'm not sure it is a window.  I guess I'm looking for some kind of display class.  Once I can settle on that, the packaging questions become easer.  Knowing the display class dictates what else gets loaded and maybe that will dictate the packaging instructions class (what gets sub classed to drive the packaging). 

To recast the question, what is the best class for this kind of display?  I need to display a picture, draw things like lines, numbers and letters on the picture, in a non-permanent way, meaning they move over the picture with out leaving artifacts.

You might want to look at the low-level Cg classes. I don't have an image open in front of me, so I am going by memory.

I think there is a CgDisplay class which represents the entire display surface. There are also various bitmap classes (or similar) which you can render on and then display one on the display surface while preparing the next one, etc.

The Gc stuff is pretty low-level, but if you're not trying to build an ABT components view, it may be enough. Perhaps the Common Widgets layer would be the better place, but it might be biased toward an overlapping windows UI and have too many impediments for what you are trying to do.

Thanks for any ideas.

Lou

On Wednesday, October 31, 2018 at 10:41:34 AM UTC-4, Louis LaBrunda wrote:

Hi Guys,

I'm working on a program targeted for the Raspberry Zero running the full GUI version of Raspbian.  That said, I don't consider this a Raspberry question but a Linux GUI packaging question.  I'm not at the packaging stage yet but what I intend to do is odd enough that I want to start thinking about packaging and get as many ideas about it as I can.

The program will display pictures on the screen.  There will be no mouse or keyboard support.  Instead, control of the program will be via the same kind of Seaside interface as my RaspberryRelay program that I have posted about and demonstrated here.

Normally when packaging a GUI program the main window is the focus of the packaging and the resultant image and executable.  Also, normally when packaging a Seaside program (headless), one picks a class to get things started and that is sort of the focus of the packaging.  Just an image is created and the supplied headless executable is used.

I think I'm going to need to use the X version of the executable (es on Raspbian) but an executable of the same name as the program is not needed as no one is going to be double clicking on it.  This brings me to another question.  The "main window" is not a main window in the normal sense.  It is for display only.  What is being displayed will change but the viewer doesn't key anything in or use a mouse.  Do I need a "normal" window or is there something else I can use.  I think I have seen classes that are not normally considered part of a GUI app and can be loaded in a headless image for popup messages to some console (I may be wrong about this).  Can anyone point me in the right direction for the screen display class.

Should the screen display class be the focus of packaging and therefor the start of the program and then it starts the Seaside stuff or the other way around?

Lou