On 18 March 2015 at 23:22, Gehad Elrobey <gehadelro...@gmail.com> wrote: > Hello Lubomir, > > I am attaching a draft of my proposal in pdf format, Please review it. > your feedback is most welcome :)
Gehad, your application is very well formed. other students can take this into account when they write their own applications. here are some entry level notes and questions that will emphasize on eventual topics of interest for the *actual* user base. > Pre Existing layouts technical information > ● Supported Paper size : A4 – A5 > ● Supported Quality : 300 dpi > ● Supported Orientation : Portrait we need to extract settings from the QPrinterDialog and from the user configuration QSettings and adjust the CSS ".media" related sections before the pagination. i'm pretty sure this is doable. > III. Design solid ideas. we may have to adjust the naming of the classes slightly (e.g. just Printer instead of CustomPrinter), but we also have to consider the support for social networks, related class names and to plan the class inheritance. > Grantlee templates > This are the preexisting templates that can be used directly. yes, keeping the current templates is nice. > Figure(3.1) Printing block diagram the graph looks good. if can you visualize what i mean by the above comment about QPrinterDialog, basically the CSS / HTML will be fed (e.g. with search-and-replace amends) with stored settings in the user configuration (from QSettings) and also with on-the-spot configuration such as margins, orientation etc. from the QPrinterDialog, then QPrinter will receive the rendered result as a paint device. > Rendering the QWebView will take place by scrolling the QPainter viewport > over the > whole content as shown in Figure(3.2) hmm, when i experimented with a paginated CSS template there was no need to scroll the viewport and QWebView simply, magically paginated my pages with render(). i may be missing something, but if you think that the viewport rendering is better i'm glad to hear why? > The proposed new dialog figure(3.4) nice, in general this is the idea about the new dialog. user suggestions are welcome about this one. > Template options the 3 tabs cover what is required pretty much. how do you plan to generate the previews BTW e.g. QWebView rendering some sort of default contents on a QPixmap that is placed in the dialog? user suggestions are welcome about the layout and functionality listing of the dialog. > General > user can choose paper size, printing quality, margin size. all of these seem fine to be on the rendered side (e.g. Chrome has them), but if the user chooses something from the printer dialog (lower level - read closer to the OS and hardware) we may have to override some of them with or without notification. > Style > user can control the font, font size, and colors. > random color generator can be included. nice. users will surely voice about more things in here. we should keep this tab's contents to a minimum at first, but best would be to consider a QScrollArea, just in case, as the CSS flexibility will open more feature requests. there are two options here. the contents of this tab: 1) should make sense for any possible template. 2) will update based on what is copy-pasted in the next tab option 1) is much easier as we don't have to deal with the dynamic creation of Qt UI. we may have to discuss this further. but i would say, consider 1) for now... > Template > this will add the ability to change the source code of the template, this > will provide very > advanced customization and the ability to change where and how does the data > appear. an "update" button will be needed to re-visualize the theme in the preview. > 1 dive per page > 2 dives per page > 4 dives per page > Flow layout > Column flow layout i'm sure "Flow layout" and "Column flow layout" will be good examples for what is possible with the new template stack. > A. Milestones > B. Timeline it's up to you how you are going to plan your work. here is how i will proceed, but i don't want to change your planned workflow much: i would start by cleaning absolutely *all* details on the UI part, which is usually the most demanding and pretentious part - i.e. there are users involved :-). then, i would sit for a while and think of how i'm going to organize all the functionality in terms of code, naming, classes, inter-module communication and so on. (keep in mind we also have to safely remove the current printer related classes). starting with Grantlee backend seems about right. i would feed it with some basic templates, until the QWebView renderer part is done. only at that point i would start implementing some of the templates and the UI changes. > VII. Documentation > A. User-Manual > I ll document the new printing features in the user manual. > B. Online tutorial > I will write an online tutorial (may be on subsurfacedivelog.org ) to > describe > how to create a new template and use it with subsurface printing module from > scratch. that would be much appreciated. ------------------------- this thread and the planned features are open for discussion. thank you for the application, Gehad. nicely done. lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface