I can find a few thousand examples of creating new windows with electron, and how to change out the current main windows to a new file, But I'm really stumped when it comes to being able to smoothly transition between pages.
I could build all the functionality into the index and swap it out, but that seems overly complex and load heavy.
I could use one of the react bootstraps but this seems rather heavy on learning and counter intuitive to Electron (Plus a massive amount of messing around with multiple package loaders and other such things I've seen).
I've seen some things in the docs for child windows and seem someone suggest the use of those, or hidden windows to pre-load content, append onto the existing page, animate then remove the old. But that just sounds like a nightmare when it comes to adding event listeners.
I just need a way to be able to transition nicely between say a splash page and a load page, then the app page
Then say in the app transition in a modal
Personally I use multiple windows and if the user clicks on the close button for one of them I do not perform a window.close() but a hide(). In addition on every close button press I check if at least one window is left to keep the app alive. If not I exit the application. For ipc calls I introduced a naming convention like: "settings_win-operation1", "splash_win-operation1" and so forth.
Related
I have 2 questions.
On some WordPress themes, they apply JQuery effects only on the
visible contents. For example, 3 div blocks in bottom of the page
are hidden at the beginning and fade in slowly when I scroll to the
bottom. What technique they used or what event they catch whenever
the content is visible?
I saw some websites having multiple slideshows, text scrolling...
How can they run so many tasks at once? To my way of thinking, they
must assign the tasks to many background worker. Each worker have
different timer to take care of the effects. Am I right? I asked
this question because based on what I read, JavaScript is single
threaded so running multiple tasks is not possible.
I'm not trying to do something with WordPress, just want to know how they can do that so I can try to rebuild it and apply to my own project.
Oculus Connect 3
I know this site was built on react. I want to know more about how to get that background animation and mouse over effect. It's simply awesome to experience. Based on this I will decide to go with React or Angular 2.
If you open your browser's inspection tool (almost always F12) you can see the layout of the webpage. It contains a canvas element with the id "grid". The animation is made using this.
The animation itself looks like a simple node graph, where if you move your cursor the nodes close to the cursor try to stay away from it, thus creating an explosion-like effect.
If your cursor stays fix for 2-3 seconds, the animation starts using a point going randomly across the page instead.
I doubt this animation uses too much of any of the libraries you mentioned in your question, thus deciding which one of these you will be using based on this demo (which let's be honest, max 200 lines of vanilla JavaScript) is like deciding what you eat for breakfast based on the food statistics of Mongolia.
And also, animations like this are what scares off most users. I don't think you can show me any big multimedia or social network site, which has animation close to this.
I'm working on a music editor/sequencer app that will be written in JavaScript+HTML5 and will make use of the canvas element and Chrome's Web Audio API (I already have a simple prototype working).
One of the things I'm not so sure about is how to implement the GUI for this. It will need to have many different views, and I'd like to perhaps have each view in a different clickable "tab", with one tab in the foreground at a given time and all the others hidden. I'm just not sure how to go about implementing all these tabs.
Would it be better to implement each tab as a different HTML layer and have buttons control which layer shows up on top? Would it be better instead to (re)generate HTML on the fly when the tab buttons are pressed?
Your advice is appreciated.
Would it be better to implement each tab as a different HTML layer and
have buttons control which layer shows up on top? Would it be better
instead to (re)generate HTML on the fly when the tab buttons are
pressed?
I would lean towards generating the content once and showing/hiding it on demand especially if the majority of work is done in the browser and there are no synchronous requests being made to a server when interacting with elements on the page.See footnote 1
When showing a tab's contents...
Assuming the content of each tab generates quickly, you can make your application more efficient by only creating the content for the tab when it is requested the first time. This way, if the tab is never accessed no resources are used.
When hiding a tab's contents...
When working with multimedia you may need to perform additional actions when you hide content. For example, a video won't stop playing just because you hide it. For your audio application you may need to stop playback of the current sequence.
There are many tab controls available such as jQuery UI tabs (free) and Sliding Tabs (licensed but inexpensive).
Other Scenarios
Tabs should be used for switching between major blocks of content like documents (e.g. browser tabs) and/or regularly used functionality (e.g. a personnel form which has a tab for contact information and another for employment history). Other scenarios may be better suited to a dialog (modal or non-modal).
Using the audio example, if you had a button labeled "tempo", I would expect it to open a small dialog window on top of my current view rather than taking me to a new tab. Roland's workstation keyboards use this paradigm. Major content replaces the current view, but settings/configuration windows usually popup atop the existing view.
jQuery UI also has a dialog plugin for this purpose. If you are JavaScript savvy and targeting newer browsers, it's not that hard to write your own simple dialog.
1 Generating content on the fly may still be perfectly acceptable with an interactive client-server relationship, but it introduces additional considerations, such as the synchronization of what is in the browser with the data model on the server (if any), the submission of unneeded form fields (increasing the size of the request), overall page size, etc.
I would suggest checking out the JQuery UI library. More specifically, the tabs functionality that it provides, http://jqueryui.com/demos/tabs/.
Simple rule of thumb for loading data into your tabs. Small and Simple, load it up front. Large and Complex, load it on demand. When in doubt, load it on demand.
if you're looking for a complex UI, I recommend you check out Dojo or Ext JS. They both provide you with a UI framework closer to Java's Swing framework.
However, if you're looking for tabs, and tabs only, jQuery UI is great.
If you're working on a canvas, do your GUI on your canvas. Seriously. Using divs in front of a canvas is just boring. I tried both, and I prefer using canvas.
The easiest way is to create a "button" class which will take an image and define a clickable zone on your canvas for this image (if you want pixel-detect there is a way which uses offscreen canvas and getpixel to check colors under the mouse and stuff, too long to explain here).
Then once you have your button or whatever gui class, you can put them on your canvas and you won't have to manage multiple html elements.
Also, some html elements in front of a canvas often have weird behaviours. That's why I prefer creating my gui directly on the canvas. Harder at the beginning but proper.
Of and please, make it possible to place multiple squares without having to reclick (just use a mouseDown variable)
I'm developing an iPad app using PhoneGap and jQuery Mobile and I'd like to create a preview pane in a carousel. The preview pane would include a smaller version of each of the other panes, scaled so they fit inside the single pane. The panes are not static and can be updated at any time using WebSockets, and the preview should be updated simultaneously. There can also be any number of panes (although to keep things simple, assume an upper limit of 9). For performance purposes, assume each pane can have upwards of 200 DOM objects attached to it. To make it slightly more complicated, the carousel can exist on more than one different page.
I've been contemplating the best way to go about implementing this preview pane, and, before inventing a pair of Complicator's Gloves, would like to hear back from the community on any possible better strategies.
A couple methods I have been considering include:
Cloning each pane and then using a CSS transform to scale it to an appropriate size, based on how many panes there are, and then attaching the clones to the preview pane.
Store each pane as a jQuery object in a variable and draw each pane and the preview pane using that object (possibly necessitating redrawing the entire carousel every time there is an update, depending on how much effort I want to make identifying and updating deltas).
Repositioning all the panes so that they exist inside the preview pane when the preview pane is active (this might break the carousel, or at least make it look slightly bizarre as a user swipes a pane over but hasn't actually moved on to that pane yet).
Is there anything I'm missing? It would be nice if there was an easy way to "link" two elements together to make one mirror the other, but apply different CSS to one or the other (for zooming). I suppose it might be possible to do this by creating an event that would fire and then adding a listener to its clone, which would then copy the html of the updated element to itself (probably wouldn't be too terribly to difficult to write a jquery plugin to manage this).
Any better suggestions?
I am not sure what phonegap allows for as far as rendering options go, but my first instinct would be to take a screen shot of the relevant pane. Perhaps phonegap has this built in?
Another option is a javascript library which will clone the DOM and create an HTML5 canvas element. You can either then display the canvas natively, or convert the canvas data in to image data.
Here is one such library: http://html2canvas.hertzen.com/
Given the large number of elements needed, I would hesitate to clone those over and over again. However, if live previews are a necessity, that might be more efficient than using image files or the canvas. You could fire off the canvas draw function after major changes, but probably wouldn't want to do it after the end of every frame of animation.
I'm developing a HTML-based iPad application that makes heavy use of JavaScript for its UI. GUI is going to be magazine-like i.e. chopped into screens/views that the user then navigates between with touch events and webkit transitions. All of this runs locally on an iPad (via a native wrapper such as PhoneGap, etc.).
Lets say the application is going to have 50-100 of those screens - filled with standard web elements like text, images, tables and forms.
How to structure that for best performance? Which of the following 2 methods is preferable and why?
having only 3 immediate (current, previous, next) views/screens in DOM and then appending new ones (and deleting the old ones) into DOM as the user navigates forward/backward?
having the entire 50-100 HTML screens generated at start and then hiding (display:none) all of them but the above 3
So basically what works better memory/performance-wise? From one side continuous DOM operations might be costly (and worse make the transitions between app screens jerky) - and from the other side - don't know if having up to a 100 HTML screens pre-generated in a single document DOM won't make Mobile Safari choke to death. Of course even though those screens are in DOM, most of them are display:none most of the time - but is the mobile safari garbage collector that good? Has anyone tried this out?
BTW please note that this is not an image-memory problem/leak type question. I'm aware of that problem and will be handling it via small-dummy-image unloading trick no matter which way I go. This is only about HTML views - skeletons if you will.
If the content is all going to be downloaded to the device at the time of launch, and everything is locally cached, then definitely go with the first method, as it will have a significantly smaller memory footprint.
If the content is downloaded on the fly, however, I would go with a mix between 1 and 2... probably prefetching and rendering the next two or three slides in either direction, or maybe one in each direction and one for each link on the page.