Feature Question
I was about to write some tab mechanism for my xtermjs terminal when I suddenly found this tabindex="0" attribute on xterm element:
<div dir="ltr" class="terminal xterm" tabindex="0">...</div>
Are there any plans to add or is there already any mechanism to add xtermjs tabs support? I couldn't find anything on that in docs.
The tabindex attribute is meant to make an HTML element focusable by tabbing, thus enables xterm.js to receive the focus, which is what most ppl want in a mainly keyboard driven env.
If you mean tab mechanism is a sense of several stacked xterm.js outputs - nope thats def. not planned. For that you'd need multiple terminal instances, xterm.js only delivers the abstraction for one instance.
Related
I want to completely disable the spellcheck features of all browsers on specific (at least) inputs.
The context:
I am developing a spelling learning game where users (primary students) are taught spelling and they have to type in words. If they can use the spelling check of the browser, that defeats the purpose of the game.
I already apply spellcheck="false" on the inputs but the command is still available in the context menu.
I don't want to block the context menu as it may be useful to some users.
Is there any way to block the access to this feature? I guess it might be different from one browser to another.
Thanks for your help.
Ben
I know that we do not have a table\datagrid component for flex mobile apps. Currently I am developing an iPad app, in which I am using datagrid(though it says it's not optimized), which works quite well on iPad. There were no scrolling issues(which I felt would be present). But only problem is while switching the tabs below, it takes very long time to move from one tab to another(it just hangs for few seconds before moving). When i removed datagrid, it was working fine again. Switching was fast as expected.
Hence i do not want to really use datagrid. I came across an alternative which says to use List\DataGroup with itemrenderer. But not sure how we can display around 10 columns. We can use a list with a label item renderer and we can adjust the space between each column value, something like this:
data.firstColValue data.secondColValue .....
But with this, I will not get the datagrid's column width increasing\decreasing functionality, which is very much needed in this project.
Is there a way in which we can remove heavy functionality and retain only core functionality(which is needed here) from datagrid? If not, are there any other alternatives with which I can achieve desired result?
Apache Flex has accepted donation of Mobile Datagrid component, so you may expect to see the component baked into future release of Flex Framework.
Is there a way in an epub file to say that a block should not be split among multiple pages, so that if the current page don't have enough room to show the block, then the block should start on the next page, instead of starting on the current page, and then spill over to the next page.
If this is not possible in general, a solution which work in ibooks and which don't cause problems in other readers are also useful :-}
I haven't played with them myself, but you might want to take a look at the .css widows and orphans styles. They are supported by the 2.0.1 spec here (scroll down to the paged media section). Setting the number high enough on your paragraph style might do the trick.
Use page-break-inside: avoid;. However, as others mentioned, you should not expect this to work on every platform. The only absolutely fool-proof way to get something to start on a new page on all readers is to place it in a separate XHTML file.
What is the right way to design the page structure of a WebWorks app? I'm using jQuery-mobile as well.
A: Should all the pages be in a single HTML, each page being a:
<div data-role="page">...</div>
B: Should pages be separated in different HTML files linking to each other?
I am currently using approach A, but the app is a slow when transitioning from a page to another. I suspect one of the reasons is the size of the single HTML that includes all pages.
Also another issue I'm having is that pressing the physical "back" button on the phone exits the app which is another reason I'm doubting my approach in having all pages in one HTML.
A very opinionated answer: You're using the wrong framework. jQuery Mobile is extremely bloated and I've seen it perform poorly even on recent iOS devices, not to mention BlackBerry's not exactly very performant OS.
If you continue to go down the jQuery Mobile route, I would still recommend you have all your pages in a single HTML file, not least because the user experience on WebWorks is a bit sub-par when moving between separate HTML pages. For example, you'll get very noticeable "white flashes" when you follow a link to a different HTML file, especially on older/less powerful devices (although you can mitigate that a bit by setting a background colour for your rim:loadingScreen element in the config.xml). It's up to you to decide whether that is better or worse than the slow transitions in jQuery Mobile.
As for the back button, you can override the default behaviour by attaching an event handler to the back key like so (don't forget to have the blackberry.system.event feature enabled in your config.xml):
blackberry.system.event.onHardwareKey(blackberry.system.event.KEY_BACK, function() {
// Back key pressed, go back to previous screen
}
If you're still open to an alternative solution though, I highly recommend you give bbUI.js a try (https://github.com/tneil/bbUI.js) - it's a semi-official framework that looks a lot more at home on the BB than jQuery Mobile and is better optimised for the platform (e.g. allowing you to only load scripts that you need for the particular page you're showing at that very moment, working around some WebWorks/BB-specific issues, etc.) - combine it with Zepto (http://zeptojs.com/) which is a blazingly fast jQuery replacement and you'll end up with an app that is significantly less sluggish than a jQuery Mobile based one.
You can use which ever way suits your project best. For a large app, it's probably worth having a single "index.html" which then links off to several other pages. Can make editing your code easier as well.
I'm considering different user interface layouts for my next project and I was wondering if there are either integrated or 3rd party frameworks which allow me to create tabbed document interface?
To clarify, what I want is not some kind of docking mechanism or either an MDI interface but primarily a framework which allows me to have one main form and one or more secondary forms which will be shown as tabs inside the main form.
Though I said I don't want any kind of docking mechanism, I made a small test application that actually uses it. The result I got is very close to what I want. First, I miss some features like the close button on each tab. Second, I'd have to create some kind of framework of my own in order to automate all tasks, like creating and destroying the tabs, associating each new form with its tab, freeing the form when the associated tab is closed and so on. I'm not saying I can't do it but I'd like to know if there are any ready-made frameworks which already have all these features. Though I'd prefer an open source solution, a commercial one is also welcome.
Third-party components are not mandatory here.
You can use standard Delphi controls to obtain what you want:
Put a TPageControl on your form (from Win32 tab);
Set its Align property to alClient;
Right click on the control, then select "New page" to add a new page.
Then don't write your "tabbed" interface on forms, but on frames.
You can also create pages by code, displaying the frame inside each page.
I don't think there is any framework for tabbed interface, but for nice looking tab/page controls with close buttons on each tab, please check the following:
rkSmartTabs, it simulates Google Chrome browser's tabbed UI. and it's open source.
TAdvOfficePager, MS Office style.
Hope it helps.
I recommend using a tool bar(TToolBar or any similar) and frames(TFrame) in order to mimic tabbed interface, reason?! well Delphi is going cross platform(no secret in that) they will port most if not all of the standard VCL shipped with Delphi, so WHY NOT use this as an advantage?
Just create the frame(dynamically) when the user clicks on a button from tool bar and destroy the previous one(if exists) so you will keep memory usage at minimum, application startup/shutdown time will be very good, on the other hand, if you chose to use (cx)TPageControl, TAdvPager, etc. you might get caught in a situation in which one form(the main I suspect) will have so many VCL's that it will take a lot of UNNECESSARY memory and it will be slow.
Using frames has a lot of advantages, if somewhere in your application you need a "tab" to be shown, you can simply create the needed frame dynamically and use it without additional work.
Anyways, this is my two cents, hope this helps.
I recommend TvjPageList, which is part of the JVCL suite of components. It's open source and seems to fit your requirements.
I use JVCL JvDocking, and its tabbed docking system, to make MDI-like applications.
You can also float, or tile your windows, in addition to having them in tabs.