Re: [racket-users] Splitting up a GUI source file?

[HiPhish]

Thank you for the paper. I had come across units several times, but I could 
never figure out *what* their intention was from the documentation. The 
paper has at least made their motivation clear, I still have to figure out 
how to actually use this feature now.

On Friday, March 23, 2018 at 6:33:27 PM UTC+1, Matthias Felleisen wrote:
>
> ...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Splitting up a GUI source file?

[James Platt]

> May be relevant
> 
> https://pkgs.racket-lang.org/package/spreadsheet-editor

Indeed, I got part way through working with that package for this exact purpose 
but ran into glitches.  The main thing is just a lack of documentation.  At 
this point, I am favoring the idea of borrowing qresults-list% from the 
Activity Log2 application as mentioned previously on this list (quoted below.)  
Unfortunately, I probably won't have time to get back to the project until May.

On Mar 5, 2018, at 4:00 PM, Alex Harsanyi wrote:

> If you want to look at a possible implementation, I wrote a wrapper around 
> list-box% for exactly the purpose of showing SQL query results in a 
> list-box%.  It supports sorting, adding, deleting and updating individual 
> rows, and you can also reorder and resize columns and this layout is saved 
> and can be restored:
> 
>https://github.com/alex-hhh/ActivityLog2/blob/master/rkt/widgets.rkt#L982
> 
> The name of the class is `qresults-list%` and you can find usage examples of 
> it throughout the application.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Splitting up a GUI source file?

[Stephen De Gabrielle]

May be relevant

https://pkgs.racket-lang.org/package/spreadsheet-editor

s.

On Fri, Mar 23, 2018 at 5:09 PM, James Platt  wrote:

>
> > I am trying to create a GUI program, my problem is that the source code
> for the
> > GUI portion is growing out of control and I don't know how to split it
> up.
>
> I'm not sure if this will really answer your question but you may want to
> look at some code from MrEd Designer and see how it splits stuff up.  It
> generates all the GUI code in a file which you then include in a file with
> the logic you write.  Following this approach, you could probably have more
> than one GUI file which you could include in your top level file.
>
> >
> > Here is some background info: the GUI is basically just a specialised
> frontend
> > to a database, the users clicks some stuff, the corresponding query is
> > constructed and sent off to SQLite using the db library.
>
> Actually, I've been thinking about learning about how to create MrEd
> Designer widgets in order to add some elements which would be useful for
> database clients.  This would include editable tables, like you mention.
>
> James
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Splitting up a GUI source file?

[Matthias Felleisen]

SHORT: You may wish to *look* at the first units paper at 

   https://www2.ccs.neu.edu/racket/pubs/#pldi98-ff
 
because what you describe is almost exactly the example from that paper. 
Just read the example section. If you like what you see, jump into the
docs. 

;; - - - 

SOMEWHAT LONGER: People usually shift a compile-time organization 
to a run-time one when confronted with this situation, that is, 
the desire to split such things in a static, tree-shaped world. 

The code then exports functions that when called with proper 
callbacks create the desired code and perform properly. What 
you give up then, is a compile-time confirmation that these things 
match up. 

Units solve this with support for mutually referential components. 
To some extent they are independent of modules and you can use 
modules with units just fine. 

Historically, units were our first module system but getting syntax
export/imports right is easier with first-order modules. 

— Matthias






> On Mar 23, 2018, at 11:39 AM, HiPhish  wrote:
> 
> Hello Racketeers,
> 
> I am trying to create a GUI program, my problem is that the source code for 
> the
> GUI portion is growing out of control and I don't know how to split it up.
> 
> Here is some background info: the GUI is basically just a specialised frontend
> to a database, the users clicks some stuff, the corresponding query is
> constructed and sent off to SQLite using the db library.
> 
> The layout is to have one main window with a tab view. The application is
> supposed to manage a small library, so each tab shows either the books, the
> users, or the rentals. Here is a simple tree-view of the GUI:
> 
>   main window
>   |
>   |-- main tab view
>   |
>   |-- Books pane
>   |   |
>   |   |- List view of books (a table)
>   |   |- Button to add a new book
>   |   |- Button to remove a book
>   |   |- Button to rent out a book
>   |
>   |-- Users pane
>   |   |
>   |   |- List view of users (a table)
>   |   |- Button to add a new user
>   |   |- Button to remove a user
>   |
>   |-- Rentals pane
>   |
>   |- List current rentals (a table)
>   |- Button to remove a rental
> 
> 
> I might reconsider the rentals part, but that's not relevant at the moment. My
> problem is that even though the three panes don't need to know anything about
> each other, they need to know about their parent (the main tab view), I cannot
> split the code into a module hierarchy like the tree.
> 
>   (define main-window (new frame% [label "Library"]))
>   (define main-tab-view (new tab-panel% [parent main-window]))
> 
>   (define books-panel (new vertical-panel% [parent main-tab-view]))
>   (define books-table (new list-view% [parent books-pane]))
>   (define books-buttons-pane (new horizontal-pane% [parent books-panel]))
>   (define add-button (new button% [parent books-buttons-pane]))
>   (define remove-button (new button% [parent books-buttons-pane]))
>   (define rent-button (new button% [parent books-buttons-pane]))
> 
> 
> And so on. This isn't much code, but add in all the callbacks and events, and
> repeat that for all the three views, and the code quickly starts adding up.
> How should I break it up into smaller modules?
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Splitting up a GUI source file?

[James Platt]

> I am trying to create a GUI program, my problem is that the source code for 
> the
> GUI portion is growing out of control and I don't know how to split it up.

I'm not sure if this will really answer your question but you may want to look 
at some code from MrEd Designer and see how it splits stuff up.  It generates 
all the GUI code in a file which you then include in a file with the logic you 
write.  Following this approach, you could probably have more than one GUI file 
which you could include in your top level file.  

> 
> Here is some background info: the GUI is basically just a specialised frontend
> to a database, the users clicks some stuff, the corresponding query is
> constructed and sent off to SQLite using the db library.

Actually, I've been thinking about learning about how to create MrEd Designer 
widgets in order to add some elements which would be useful for database 
clients.  This would include editable tables, like you mention.

James

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Splitting up a GUI source file?

[HiPhish]

Hello Racketeers,

I am trying to create a GUI program, my problem is that the source code for 
the
GUI portion is growing out of control and I don't know how to split it up.

Here is some background info: the GUI is basically just a specialised 
frontend
to a database, the users clicks some stuff, the corresponding query is
constructed and sent off to SQLite using the db library.

The layout is to have one main window with a tab view. The application is
supposed to manage a small library, so each tab shows either the books, the
users, or the rentals. Here is a simple tree-view of the GUI:

  main window
  |
  |-- main tab view
  |
  |-- Books pane
  |   |
  |   |- List view of books (a table)
  |   |- Button to add a new book
  |   |- Button to remove a book
  |   |- Button to rent out a book
  |
  |-- Users pane
  |   |
  |   |- List view of users (a table)
  |   |- Button to add a new user
  |   |- Button to remove a user
  |
  |-- Rentals pane
  |
  |- List current rentals (a table)
  |- Button to remove a rental


I might reconsider the rentals part, but that's not relevant at the moment. 
My
problem is that even though the three panes don't need to know anything 
about
each other, they need to know about their parent (the main tab view), I 
cannot
split the code into a module hierarchy like the tree.

  (define main-window (new frame% [label "Library"]))
  (define main-tab-view (new tab-panel% [parent main-window]))

  (define books-panel (new vertical-panel% [parent main-tab-view]))
  (define books-table (new list-view% [parent books-pane]))
  (define books-buttons-pane (new horizontal-pane% [parent books-panel]))
  (define add-button (new button% [parent books-buttons-pane]))
  (define remove-button (new button% [parent books-buttons-pane]))
  (define rent-button (new button% [parent books-buttons-pane]))


And so on. This isn't much code, but add in all the callbacks and events, 
and
repeat that for all the three views, and the code quickly starts adding up.
How should I break it up into smaller modules?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.